Community
Participate
Working Groups
Build Identifier: 1.6.6.20090930185500 Hi all, in my integration test plugin I'have an aspect [1] inheriting another base aspect [2] defined in another plugin. During compilation (even a full AJDT rebuild) I'm receiving the following error (I think it is a bug): java.lang.NullPointerException at org.aspectj.weaver.model.AsmRelationshipProvider.addRelationship(AsmRelationshipProvider.java:143) at org.aspectj.weaver.bcel.BcelTypeMunger.munge(BcelTypeMunger.java:127) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:448) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:103) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1810) at org.aspectj.we ... nelope.test.EventDispatchIntegrationTests$EventReceiver) end public class it.uniba.di.cdg.penelope.test.EventDispatchIntegrationTests$EventReceiver If I put the abstract base aspect into the same plugin as the derived one and perform another clean rebuild it weaves with no error. I'm using Spring Tool Suite 2.3.0 which includes the latest 2.0.1 (but the latter does not include AspectJ 1.6.7 that has been released recently so I don't know if the bug is fixed). Note that the error only happens during workspace rebuild: if I clean & rebuild only my integration tests project no error happens but only some pointcuts are matched. [1] http://code.google.com/p/penelope-rcp/source/browse/trunk/it.uniba.di.cdg.penelope.test.integration/src/it/uniba/di/cdg/penelope/test/EventDispatchIntegrationTests.java [2] http://code.google.com/p/penelope-rcp/source/browse/trunk/it.uniba.di.cdg.penelope/src/it/uniba/di/cdg/penelope/events/AbstractApplicationEventEnhancerAspect.aj Reproducible: Always
I verified that the same error occurs with AJDT 2.0.2 (with aspectj 1.6.7a)
Created attachment 155433 [details] testcase The attached testacase contains two projects: one with base aspects and one with integrations tests. When I do a clean-rebuild the following error is displayed (AJDT 2.0.2): java.lang.NullPointerException at org.aspectj.weaver.model.AsmRelationshipProvider.addRelationship(AsmRelationshipProvider.java:143) at org.aspectj.weaver.bcel.BcelTypeMunger.munge(BcelTypeMunger.java:126) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:448) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:103) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1831) at org.aspectj.we ... ewEnhancerAspect$it_uniba_di_cdg_penelope_ui_mvp_IManagedView$presenters(java.util.List) end public class test.ViewEnhancerIntegrationTest$MockView
thanks for the testcase, I've now recreated the failure.
the npe happens because the program element cannot be found in the model for the base aspect. Due to the base aspect being in another project it should be 'faulted in' to the model for the test project when we determine it is required, because it is considered a 'binary aspect'. Unfortunately it hasn't been flagged correctly as binary - this causes us to fail to fault it in, so the lookup fails and the NPE occurs. I can workaround this by making the test.aspects project have an aspect path dependency on the base.aspects project (Project Properties>AspectJ Build>Aspect Path>Add Project). This isn't an unreasonable requirement as it is consuming aspects from that project, but I need to think about it a little more. This workaround may work in your larger scale configuration too. Of course the NPE needs addressing but I'm not currently sure if it is by doing the correct job of faulting the aspect in, or if it should say 'hey, you need an aspectpath dependency'.
From my (user/developer) I just make tests.aspects depend on base.aspects and expect it to Just Work(TM) without any other changes. Though, I guess that having the compiler just protest istead of dying is Good Enough(TM) (given it also prints out the workaround ;)) Andy, does your solution work for plugin projects too? The testcase I wrote down is using plain aspectj projects but in real world what I'm trying to do is an RCP application: is there any issue with this kind of projects' configuration?
I think you would be OK adding this dependency for your RCP application too. The only downside that you need to keep in mind is that not only will this be addressing this bug it will also cause projects to pickup (and attempt to be matched/woven by) other aspects found on that aspectpath. If your aspects all use appropriate scoping or are all perhaps abstract and 'harmless' until extended, then there is no issue. And all this is only a temporary measure whilst I work out the best solution, that will come in an AJDT shortly I imagine, this bug shouldn't be rocket science to sort out.
test and fix committed. If we are about to NPE we have one more go trying to fault the aspect in from the classpath. With this change the aspect doesn't have to be on the aspectpath for ITDs to be discoverable when building the relationship map.
