Community
Participate
Working Groups
I defined an abstract aspect (SingletonAspect) that introduced methods and members on a marker interface (SingletonPattern). SingletonAspect also gave after advice to the staticinitializer on SingletonPattern and declared several errors pertaining to the use of SingletonPattern. Then I extended the abstract SingleAspect with an empty class (SingletonAspectImpl). Things worked as expected. Next, I jar'ed my compiled classes (SingletonPattern.class,SingletonAspect.class, and a helper class generated by ajc) and included the jar in the compile time class path of a new source tree where I again extended SingletonAspect with an empty class (SingletonAspectImpl). This time, everything compiles, but nothing works as expected. No methods or members are introduced, the error declarations are not enforced, and the advice is not present. In short, the abstract aspect's SOURCE must be present in the sourcetree for the aspect to function properly. This defeats Aspect extension outside of the present sourcetree.
It should work if you put the aspect library jar on the aspectpath. (The compiler does not weave aspects from the classpath.) If it does work, feel free to close this bug.
I know the compiler was never intended to weave Aspects that reside in the classpath, it only weaves Aspects with source in the compile path (source tree). However, it is strange to me that the compiler will not weave the inherited portions of a super aspect when the super aspect's source is not in the compile path. In otherwords, I have to have the source of the super aspect as well as the source of the child aspect in the compile path in order to see expected inheritance results. I feel this severly restricts Aspect inheritance, as I have to have the source of any Aspects I want to extend in my source tree at compile time. If this is known and accepted I will invalidate this bug.
To confirm, this is definitely a bug. A major goal of 1.1 is to allow you to provide compiled abstract aspects on the classpath that can be concretized for your specific system. You should also be able to provide concrete aspects completely in binary form (using aspectpath). This is a hard bug to fix, but it will be addressed for the next release.
This bug is mostly fixed and will be resolved in the upcoming release. However, it would still be helpful if you could submit a small self-contained test case of the problem as you see it. This will help to verify the solution on an independent test case.
fixed in current tree, tests in BinaryFormsTestCase unit test
