[STS-2068] push-in of Roo-generated converter methods in ApplicationConversionServiceFactoryBean doesn't move method to java source Created: 30/Aug/11  Updated: 06/Sep/11  Resolved: 06/Sep/11

Status: Resolved
Project: Spring Tool Suite
Component/s: EDITING, ROO
Affects Version/s: 2.7.1.RELEASE, 2.8.0.M1
Fix Version/s: 2.8.0.M2

Type: Bug Priority: Major
Reporter: MiB Assignee: Andrew Eisenberg
Resolution: Complete Votes: 0
Labels: AspectJ, roo1.2,
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X 10.5.8, jdk 1.5 (build 1.5.0_30), Roo 1.2.0.BUILD-SNAPSHOT [rev 6002fca]


Attachments: Java Source File ApplicationConversionServiceFactoryBean.java     File ApplicationConversionServiceFactoryBean_Roo_ConversionService.aj    

 Description   

When I push in a converter method from the Roogenerated ApplicationConversionServiceFactoryBean_Roo_ConversionService.aj with "Refactor -> Push-in" command the methods are not moved to the Java source file. My expectations were they were going to be moved, just like when I push-in other methods.

I'm not sure this is so by design or from a mistake.



 Comments   
Comment by Andrew Eisenberg [ 31/Aug/11 ]

Can you attach the aspect as well as the target java classes that are causing the problem?

Comment by Andrew Eisenberg [ 01/Sep/11 ]

Thanks. This should be sufficient.

Comment by Andrew Eisenberg [ 01/Sep/11 ]

Unfortunately, I was not able to reproduce with only the provided files. Can you send me the full project by email: aeisenberg@vmware.com?

Also, let me know if the source code must remain private and I will make sure that it will not be shared.

Comment by Andrew Eisenberg [ 02/Sep/11 ]

Thanks for your project. I was able to reproduce your problem at first, but that was due to an unresolved maven problem. I have upgraded to m2e 1.0 in my workspace and the pom.xml was initially causing some errors.

The result was that maven was able to compile the project, but it could not be compiled inside of Eclipse. This further meant that even though class files were generated, there was no crosscutting model.

Because of this odd state, AJDT thought that everything was ok, but the crosscutting model was empty. So, it allowed you to do a push-in even though it didn't know where to push them in to (and so they were simply deleted).

Could this be the behavior that you see? Does your pom.xml have any error markers on it? Do you see AJ gutter markers in your AJ files?

If this is the case, then perhaps the solution is to be more explicit and warn users when this kind of error occurs.

Comment by MiB [ 02/Sep/11 ]

No error markers in POM. I see gutter markers to the left in my .aj files that says on mouseover say "annotates XX".

There are other smaller problems, significantly roo-made overrides annotation for interfaces that gives errors under jdk5. The rest are just warnings. Main reason to move these to the java source. In later Roo builds the overrides are gone though.

Comment by Andrew Eisenberg [ 02/Sep/11 ]

Hmm....it is possible that these compile errors are preventing the code from compiling in Eclipse and hence push in is not working.

I'll see if I can get this behavior happening for me.

Comment by Andrew Eisenberg [ 02/Sep/11 ]

In general, there will need to be a clean compile in order to get the correct crosscutting model generated (although if the errors have nothing to do with the area you are pushing in, this requirement may not be necessary).

Are there gutter markers over the ITD that you are unsuccessfully trying to push in? And is there an associated gutter marker in the target? Also, the markers should say something like "Declared on..." and "Aspect declaration...". If they are missing, that implies a broken crosscutting model.

Comment by MiB [ 03/Sep/11 ]

No, there are no such markers I see now, also after a clean rebuild. What I saw before was probably left from an earlier build. There were no warnings about a broken crosscutting model.

I also did clean restart of STS and then autobuilt again. Still no markers. So I did another clean rebuild and now I think there are markers. Is there some way to verify they are all correct? The test run green, unless the ones that currently have design errors and could be expected to fail in the current state of the project in question.

My suggestion is that a clean restart should be a menu alternative.

Comment by Andrew Eisenberg [ 03/Sep/11 ]

Thanks for the response. What do you mean 'a clean restart'? At a minimum, AJDT should add some kind of marker when the crosscutting model is invalid or incomplete. The problem is going to be detecting when this occurs, but this is something that I can work on.

Comment by MiB [ 05/Sep/11 ]

With "clean restart" I meant I started up STS with "-clean" on a sepratate line in "STS.ini".

I could see some markers I think, but very few.

How can I help you at this stage?

Comment by Andrew Eisenberg [ 05/Sep/11 ]

Nothing right now. I'll have a look at this in the next day or two and see if I can detect when the model is incomplete (and then have the push in refactoring produce a fatal error).

Comment by Andrew Eisenberg [ 06/Sep/11 ]

I committed a fix such that pushin refactoring will do more extensive conditions checking before performing.

Now, if there are any errors in the aspect or the target type (even if they are unrelated to the ITD being pushed in). Also, it is now checking for ITDs that have no target. In either case, if an error is found the refactoring will be blocked until fixed.

The downside is that some refactrings that would have worked in the past are now blocked. However, we are also preventing situations that would cause unexpected, subtle errors like the one that you received earlier.

I think this fix covers the problem described in this issue, so closing. The fix will be available in the next dev build of AJDT.

Comment by MiB [ 06/Sep/11 ]

Thanks Andrew. Springsource/Vmware is easily one of the most responsive software companies I've been bug reporting to. An inspiration.

Generated at Thu Mar 21 16:03:10 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.