java - AspectJ - Child Classes Getting Lost -

java - AspectJ - Child Classes Getting Lost -

i'm sure amounts newbie question aspectj reviewing books , web sites, i'm not seeing reply in terms recognize.

summary: in client jar, getting compilation errors complaining methods added part of "aspect b" not present.

i have setup similar :

+---------------------+ | | | client jar | | | +--+---------------+--+ | | | | +----------+----+ +-------v-------+ | json serial / | | other aspect | | deser aspect | +---------------+ +-------------+-+ +-------v-------+ | | potential | | | other jar | | +---------------+ | +----v-----------+ | javabean | | aspects | +----------------+ +----v-----------+ | basic info | | objects | +----------------+

essentially, have 2 levels of aspects behaviors beingness extended in each layer.

assume next class in "basic info objects":

basicdataobjects sampleobject

public class sampleobject { private string name; private int age; }

and next aspect in javabean aspects:

class="lang-java prettyprint-override">privileged aspect sampleobject_javabean { public string sampleobject.getname() { homecoming this.name; } }

and next aspect in json aspects:

class="lang-java prettyprint-override">privileged aspect sampleobject_json { public string sampleobject.getnamevalue() { homecoming this.name == null ? null : this.name.serialize(); } }

finally, in actual client jar, getting next compilation error:

class="lang-java prettyprint-override">public void somemethod (sampleobject obj) { obj.getnamevalue() // <-- has compilation error getnamevalue() unresolvable. }

in client jar, getting compilation errors methods added part of "aspect b" not available.

my expectation "aspect a" generated jar file should have own classes compiled classes provided part of "aspect b".

aspect b pom:

class="lang-xml prettyprint-override"><project> <!-- (...) --> <artifactid>aspect-b</artifactid> <dependencies> <dependency> <groupid>org.aspectj</groupid> <artifactid>aspectjrt</artifactid> <version>${aspectj.version}</version> </dependency> <dependency> <groupid>com.example</groupid> <artifactid>lib-data-objects</artifactid> <version>0.0.1-snapshot</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>aspectj-maven-plugin</artifactid> <version>1.7</version> <executions> <execution> <goals> <goal>compile</goal> <goal>test-compile</goal> </goals> </execution> </executions> <configuration> <outxml>true</outxml> <compliancelevel>${java.version}</compliancelevel> <source>${java.version}</source> <target>${java.version}</target> <weavedependencies> <weavedependency> <groupid>com.example</groupid> <artifactid>lib-data-objects</artifactid> </weavedependency> </weavedependencies> </configuration> </plugin> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-compiler-plugin</artifactid> <version>2.5.1</version> <configuration> <source>${maven.compiler.source}</source> <target>${maven.compiler.target}</target> </configuration> </plugin> </plugins> </build> <!-- (...) --> </project>

aspect pom:

class="lang-xml prettyprint-override"><project> <!-- (...) --> <artifactid>aspect-a</artifactid> <dependencies> <dependency> <groupid>org.aspectj</groupid> <artifactid>aspectjrt</artifactid> <version>${aspectj.version}</version> </dependency> <dependency> <groupid>com.example</groupid> <artifactid>lib-data-objects</artifactid> <version>0.0.1-snapshot</version> </dependency> <dependency> <groupid>com.example</groupid> <artifactid>aspect-b</artifactid> </dependency> </dependencies> <build> <plugins> <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>aspectj-maven-plugin</artifactid> <version>1.7</version> <executions> <execution> <goals> <goal>compile</goal> <goal>test-compile</goal> </goals> </execution> </executions> <configuration> <outxml>true</outxml> <compliancelevel>${java.version}</compliancelevel> <source>${java.version}</source> <target>${java.version}</target> <weavedependencies> <weavedependency> <groupid>com.example</groupid> <artifactid>aspect-b</artifactid> </weavedependency> </weavedependencies> </configuration> </plugin> </plugins> </build> <!-- (...) --> </project>

client jar pom:

class="lang-xml prettyprint-override"><project> <!-- (...) --> <dependencies> <dependency> <groupid>com.example</groupid> <artifactid>aspect-a-wrapper</artifactid> <version>${aspect-a.version}</version> </dependency> <groupid>com.example</groupid> <artifactid>lib-data-objects</artifactid> <version>0.0.1-snapshot</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>aspectj-maven-plugin</artifactid> <version>1.7</version> <executions> <execution> <goals> <goal>compile</goal> <goal>test-compile</goal> </goals> </execution> </executions> <configuration> <outxml>true</outxml> <compliancelevel>${java.version}</compliancelevel> <source>${java.version}</source> <target>${java.version}</target> <weavedependencies> <weavedependency> <groupid>com.example</groupid> <artifactid>aspect-a</artifactid> </weavedependency> </weavedependencies> </configuration> </plugin> </plugins> </build> <!-- (...) --> </project>

as said in own answer, in client jar pom.xml have defined dependencies on both

the plain info objects library (without aspect code) and the aspect-enhanced info objects library after 2 stages of weaving (java beans , json inter-type declarations).

but need latter, should remove former.

that utilize weavedependencies in aspect libraries okay , necessary because otherwise not compile in scenario: aspect b needs info objects library because otherwise cannot find classes should add together new methods to. aspect b needs aspect because wants utilize aspect-enhanced library add together more methods via itd. don't think particularly nice setup because aspect b needs know aspect a, creates unnecessary transitive dependency clientjar -> aspb -> aspa -> dataobj. maybe wiser aspect-enhance info objects library straight , shorten chain clientjar -> dataobj. bad if need plain library without added itd methods in other circumstances. still create plain , aspect-enhanced version (only 1 stage of aspect enhancement, not 2 transitively dependent ones).

update, 2015-01-02:

i had leftover time , have started looking again. have ended nice solution (see github repo) next characteristics:

there parent module aspectj-multi-module, kid modules are: data-objects (application class, no aspects), no dependencies aspect-javabean (java bean-related itd aspect), depends on data-objects aspect-json (json-related itd aspect), depends on data-objects data-objects-aspectj (weave aspects core classes), depends on data-objects, aspect-javabean, aspect-json client-jar (create jar of jars containing core + aspect code, sample class main method using aspect-enhanced core class , aspectj runtime), depends on data-objects-aspectj please note both aspect-{javabean,json} modules depend on core module, no aspect module depends on other one. both aspect types woven core code in module data-objects-aspectj via binary weaving. a little trick used in order compile itd aspects, excluding woven core modules resulting aspect library because want aspects in library. in order understand trick need know difference between ajc (aspectj compiler)'s inpath , aspectpath: whatever on inpath in output directory/jar. corresponding aspectj maven config setting <weavedependency>, section <weavedependencies>. whatever on aspectpath available during compile time , not end in output directory/jar. corresponding aspectj maven config setting <aspectlibrary>, section <aspectlibraries>. so, using semantics mentioned above, core module defined <aspectlibrary> (even though not contain aspects, don't confused naming). avoids woven core classes beingness part of aspect libraries. not useful have multiple versions of woven core classes mutually exclusive aspects in aspect library because 1 should win in end? need version of our core code all aspect libraries woven in @ same time, or @ to the lowest degree take configure in module. the other module mentioned data-objects-aspectj, , sole purpose post-compile, binary aspect weaving, using input pure java core module , both pure aspect libraries. of these modules configures <weavedependencies> time, because of them should in resulting jar. in order enable binary weaving in aspectj maven plugin, need add together 1 dummy class because plugin not compile or weave if not find source files in own module. dummy class stripped output 1 time again via explicit exclusion configured in maven jar plugin. exclusion nice have, ignore dummy class in output jar. last, not least, there module client-jar adds little driver application main method whole mix in order create runnable , testable command line. driver application uses getter methods created both json , java beans aspects in order prove exist , functional. another nicety in module client-jar creation of one-jar (über-jar) containing dependencies (even aspectj runtime) , main class configuration. can run result via: java -jar client-jar/target/client-jar-1.0-snapshot.one-jar.jar finally, module client-jar contains exec maven plugin configuration straight running über-jar via: mvn --projects client-jar exec:exec. nice have, über-jar itself, why create life harder necessary? ;-)

console in-/output:

class="lang-none prettyprint-override">$ java -jar client-jar/target/client-jar-1.0-snapshot.one-jar.jar sampleobject{name='john doe', age=33} java bean properties: john doe 33 json properties: "name" : "john doe" "age" : 33

update, 2015-01-03:

i added capability create custom mix of aspects applied core code during weaving in module data-objects-aspectj means of maven profiles, see changeset 32ee5fc.

java aspectj