Community
Participate
Working Groups
Created attachment 128699 [details] sample project and before and after pictures of cross reference tab Build ID: M20090211-1700 Steps To Reproduce: 1. Open the attached sample project 2. Open the cross reference tab. 3. Open the ProcessAspect aspect. 4. Select line 10 - "public aspect ProcessAspect" 5. Perform a clean build. 6. Notice that the cross reference tab shows what you would expect... see the attached before jpg. 7. Select line 9. 8. Select line 10 again. 9. Notice that the cross reference tab no longer shows any cross reference information. More information: The cause may also be what is causing: bug 263666. However that issue was described differently.
I have another project that I cannot send to you due to the fact that it contains our company's code. In this project, the cross reference view always shows what is in the attached after picture... it never shows the cross references. The markers in the editor will show the correct number of advice points though, and the code is being woven correctly.
This is interesting. Thanks for the project. I am using it and I am finding some peculiarities. It seems like what is happening here is that the crosscutting model is changing after the build completes. It should only be changing during a build. So, what seems to be happening is that the build occurs, then markers are created. After this, the model changes and the outgoing relationships for the advice are removed from the model. This is why the advice relationships are not showing up in the xref view. They do not exist anymore. This is starting to look like an AspectJ problem, but I will look some more.
There are two advice declarations that use "thisJoinPoint". When I remove all references to thisJoinPoint (and replace with null), then the underlying crosscutting model does not change after the build. The xref view and navigation works as expected. I am fairly certain this is an AspectJ issue.
Created attachment 128834 [details] simpler project that recreates the problem This project is a simpler version that recreates the above. It seems that the problem arises when the advice has a runtime check *and* references thisJoinPoint. To recreate: 1. compile 2. try to navigate from before advice, but no navigation is possible. 3. comment out thisJoinPoint reference. Navigation works 4. uncomment thisJoinPoint reference and comment out the cflow pointcut. Navigation works
not sure I have enough to go on - I don't know what the model is when it is working or what it is when it becomes broken. I can see the behaviour as described in comment 4 (although I don't need to comment out the cflow). If I can't see the model changing, I can't do much other than confirm it is correct and see if I can see a difference with and without thisJoinPoint (I imagine the signature of the method pointing to has changed, and includes a joinpoint parameter in the former case). Can you print the model between at times when you think it is valid/invalid? The model cannot change after a build, there are no threads - and we only have one AspectJ project so it can't be another interfering. But it could be altered very late on in the build process which damages something it showed earlier (but then AJDT shouldn't be looking at it until the build is over). If I do a full build with the thisJoinPoint reference commented out - I have navigation from the gutter. If i uncomment the line to get an incremental build, I still have the navigation. To lose it I have to close and reopen the editor for the aspect. I will get the model for a full build with and without the reference and put it here.
full build with tjp: pr268522 [build configuration file] hid is =pr268522 [package] hid is =pr268522< Advises.aj [java source file] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\Advises.aj:1::0 hid is =pr268522<*Advises.aj [import reference] hid is =pr268522<*Advises.aj# Advises [aspect] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\Advises.aj:2::15 hid is =pr268522<*Advises.aj}Advises before(): <anonymous pointcut>.. [advice] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\Advises.aj:3::26 hid is =pr268522<*Advises.aj}Advises&before IsAdvised.java [java source file] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\IsAdvised.java:1::0 hid is =pr268522<{IsAdvised.java [import reference] hid is =pr268522<{IsAdvised.java# IsAdvised [class] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\IsAdvised.java:2::14 hid is =pr268522<{IsAdvised.java[IsAdvised main(java.lang.String[]) [method] C:\temp\ajcSandbox\ws34\ajcTest15152.tmp\pr268522\src\IsAdvised.java:4::47 hid is =pr268522<{IsAdvised.java[IsAdvised~main~\[QString; Hid:1:(targets=1) =pr268522<{IsAdvised.java[IsAdvised~main~\[QString; (advised by) =pr268522<*Advises.aj}Advises&before Hid:2:(targets=1) =pr268522<*Advises.aj}Advises&before (advises) =pr268522<{IsAdvised.java[IsAdvised~main~\[QString;
full build without tjp: pr268522 [build configuration file] hid is =pr268522 [package] hid is =pr268522< Advises.aj [java source file] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\Advises.aj:1::0 hid is =pr268522<*Advises.aj [import reference] hid is =pr268522<*Advises.aj# Advises [aspect] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\Advises.aj:2::15 hid is =pr268522<*Advises.aj}Advises before(): <anonymous pointcut>.. [advice] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\Advises.aj:3::26 hid is =pr268522<*Advises.aj}Advises&before IsAdvised.java [java source file] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\IsAdvised.java:1::0 hid is =pr268522<{IsAdvised.java [import reference] hid is =pr268522<{IsAdvised.java# IsAdvised [class] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\IsAdvised.java:2::14 hid is =pr268522<{IsAdvised.java[IsAdvised main(java.lang.String[]) [method] C:\temp\ajcSandbox\ws34\ajcTest50905.tmp\pr268522\src\IsAdvised.java:4::47 hid is =pr268522<{IsAdvised.java[IsAdvised~main~\[QString; Hid:1:(targets=1) =pr268522<{IsAdvised.java[IsAdvised~main~\[QString; (advised by) =pr268522<*Advises.aj}Advises&before Hid:2:(targets=1) =pr268522<*Advises.aj}Advises&before (advises) =pr268522<{IsAdvised.java[IsAdvised~main~\[QString;
no difference in the model or relationships other than the sandbox directory
> So, what seems to be happening is that the build occurs, then markers are > created. After this, the model changes and the outgoing relationships for the > advice are removed from the model. I guess these are the events for which I need to know the model. Are the relationships gone or are they simply moved around?
Here is the hierarchy and relationship map for before and after. The behavior is slightly different from what I remember yesterday. It seems that on a full build, the model is correct and then a noop change to the aspect will corrupt it (the outgoing advice relationship is lost). Below is the hierarchy and relationship map printing that is used by AJDT (see AJProjectModelFacade). (do full build) Hierarchy after full build =Bug268522/src =Bug268522/src< =Bug268522/src<*Advises.aj =Bug268522/src<*Advises.aj# =Bug268522/src<*Advises.aj}Advises =Bug268522/src<*Advises.aj}Advises&before =Bug268522/src<{IsAdvised.java =Bug268522/src<{IsAdvised.java# =Bug268522/src<{IsAdvised.java[IsAdvised =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; Relationship Map after full build =Bug268522/src<*Advises.aj}Advises&before :: =Bug268522/src<*Advises.aj}Advises&before --advises--> [=Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString;] =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; :: =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; --advised by--> [=Bug268522/src<*Advises.aj}Advises&before] (whitespace change to aspect and save---force noop incremental build) Hierarchy after incremental build =Bug268522/src =Bug268522/src< =Bug268522/src<{IsAdvised.java =Bug268522/src<{IsAdvised.java# =Bug268522/src<{IsAdvised.java[IsAdvised =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; =Bug268522/src<*Advises.aj =Bug268522/src<*Advises.aj# =Bug268522/src<*Advises.aj}Advises =Bug268522/src<*Advises.aj}Advises&before Relationship map after incremental build. Notice that the first line (for the advice) should have some relationships associated with it, but does not. =Bug268522/src<*Advises.aj}Advises&before :: =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; :: =Bug268522/src<{IsAdvised.java[IsAdvised~main~\[QString; --advised by--> [=Bug268522/src<*Advises.aj}Advises&before]
I have now recreated a case where a relationship vanishes, but only inside AJDT. After hours of debugging (adding too many breakpoints makes the problem become less likely, stupid thing) I have found a bit of code deleting things from the model which i don't think should be: java.util.AbstractList$Itr.remove(AbstractList.java:360) at org.eclipse.ajdt.core.model.AJProjectModelFacade$2.preProcess(AJProjectModelFacade.java:784) at org.aspectj.asm.HierarchyWalker.process(HierarchyWalker.java:28) at org.aspectj.asm.internal.ProgramElement.walk(ProgramElement.java:420) at org.aspectj.asm.HierarchyWalker.process(HierarchyWalker.java:29) The AspectJ model is not returning an unmodifiable list and that allows other people to damage it if they aren't careful. I will look into how cheap unmodifiableLists are and perhaps return one of those instead to stop this kind of thing.
(In reply to comment #11) > org.eclipse.ajdt.core.model.AJProjectModelFacade$2.preProcess(AJProjectModelFacade.java:784) I've changed this line to use a copy of the list rather than the original list and the problems goes away. Rather than return an unmodifiable list, perhaps you can return a copy. And internally for the sections that require speed, create a new method that returns the original list. After a quick grep through the code, it looks like the method is only used 3 times inside aspectj and about 5 times in AJDT. All of the AJDT uses are bound to the UI, so speed is not much of a factor.
I don't think my contract on that API should be to return a copy that the user can mess with (and copying it just in case anyone wants to write to it would be wasteful) - your approach to creating a copy of whatever you get back would be more sensible. But an unmodifiableList would be the cheap way to stop anyone messing with it by accident. Now we know the problematic code, can you more accurately describe the scenario which would lead to relationships vanishing? Is it something in AJDT 1.6.4? Is it something relatively common or uncommon?
I'll just throw my 2 cents in since I reported the bug. > Is it something in AJDT 1.6.4? I noticed it after installing eclipse 3.4 (with the latest ajdt) and aspectj 1.6. I did not notice this issue in eclipse 3.3 and aspectj 1.5. > Is it something relatively common or uncommon? For me it is very common. This behavior (or a variation of it) has occurred with every project I have created using aspectj 1.6 and eclipse 3.3. Other variations: - cross references never show up when viewing them from the aspect (as apposed to the advised class) - markers show up with one build and then disappear with the next - markers never show up
(In reply to comment #14) > I'll just throw my 2 cents in since I reported the bug. > > > Is it something in AJDT 1.6.4? > I noticed it after installing eclipse 3.4 (with the latest ajdt) and aspectj > 1.6. I did not notice this issue in eclipse 3.3 and aspectj 1.5. > > > Is it something relatively common or uncommon? > For me it is very common. This behavior (or a variation of it) has occurred > with every project I have created using aspectj 1.6 and eclipse 3.3. > > Other variations: > - cross references never show up when viewing them from the aspect (as apposed > to the advised class) > - markers show up with one build and then disappear with the next > - markers never show up > sorry... I meant to say "This behavior (or a variation of it) has occurred with every project I have created using aspectj 1.6 and eclipse 3.4." not 3.3. I also should have been more specific on the AJDT version I have seen this with: 1.6.4. I had the latest stable build installed and then tried the latest development build to see if it would fix the issue. Here are the ajde plugins I have installed: org.aspectj.ajde_1.6.4.20090106083800 org.aspectj.ajde_1.6.4.20090304172355 and runtimes org.aspectj.runtime_1.6.4.20090106083800 org.aspectj.runtime_1.6.4.20090304172355
This will not occur in 1.6.0 or earlier because the refactored project model was not introduced until 1.6.1. This problem will occur whenever multiple kinds of relationships apply to a single program element. Eg, when there is an Aspect Declarations and an Annotated by relationship on a type. I think this is a critical bug that must be added to 1.6.4.
appears to be AJDT.
I committed the fix for this. It is now in the AJDT 1.6.5 dev build (available from the dev update site).
And both projects now work as expected.
