Community
Participate
Working Groups
Adding a RFE as Wes suggested... Wes' reply: There are some issues with the -Xnoweave option that we won't have the time to carefully resolve for 1.1, even though, as you suggest, there may be times when it would be useful. The workaround at present is to weave tracing into transactions when the transactions jar is compiled. e.g., -- do the build ajc @tracing.lst -outjar tracing.jar ajc @transactions.lst -aspectpath tracing.jar \ -outjar transactions.jar ajc @app.lst -aspectpath "tracing.jar;transactions.jar" \ -outjar app.jar -- build the jar mkdir final cd final jar xf ../tracing.jar jar xf ../transactions.jar jar xf ../app.jar # fixup manifest, etc? jar cf ../final.jar * What if you don't have the sources for the transactions.jar? This is a case of getting binary transactions aspects from a vendor who won't provide source and wanting to weave your tracing into it. I would hope that by the time that problem becomes prevalent, we will have a solution for it. If you'd like to keep this on the radar, please submit this discussion as an RFE for the compiler at http://dev.eclipse.org/bugs/enter_bug.cgi?product=AspectJ Thank you - Wes P.S. - Personally, I think this case > > ajc -injars app.jar;transaction.jar > -aspectpath transaction.jar;tracing.jar doesn't make sense. Things on the aspectpath are defined, whereas things in injars will be woven into and redefined. It's not clear from this command which variant the user expects when refering to a type in transactions.jar. Ramnivas Laddad wrote: > > Hello, > > I think I have a use case that cannot be implemented > (at least elegantly, anyway) without noweave/XnoWeave > option (and thus I request to make it a regular option > instead of experimental -X). > > Basically, I want to have my tracing.jar ( > contains tracing aspect) weave into transaction.jar > (contains abstract transaction mangement aspects, > concrete policy enforcement aspects, and supporting > classes). Assume app.jar contain business classes > and interfaces. Each of the jar is created using > -ourjar (but not -noweave or -XnoWeave). > > To build the final system I issue the following > command: > > ajc -injars app.jar;transaction.jar > -aspectpath transaction.jar;tracing.jar > > Now compiler gives me error due to multiply woven > classes and aspects in transaction.jar. > > Everything works fine if I create the original jar > files using -noweave. > > I could workaround by creating multiple jars, but > I hink -noweave is the right approach as > I really don't want to ship multiple jars that are > needed to implement a single concern and expect the > users to correctly specify jar files in -injars > and -aspectpath. > > -Ramnivas
Marking this as an enhancement request for consideration in 1.1.1
We should add a –Xreweavable option to generate classfiles that will have enough additional information in them that they can be rewoven. The goal is that in AspectJ-1.3 (or maybe even 1.2.1) this option can become a standard option and the –Xnoweave option can either be removed or left as an X option forever. In addition to Ramnivas’ example, this option is very important as we start to provide standard support in AspectJ for load-time weaving. In this case we definitely need a standard supported option for building libraries with AspectJ that can be safely passed to a load-time weaver. The reweavable option is better than the noweave option in many ways. The most significant benefit is that it will produce classfiles that can be legally loaded by a JVM. The noweave option makes it much too easy to produce verify errors. In addition, the reweavable option will make it easier to weave code many times without having to decide which weave is the final one. Ideally, producing reweavable classfiles should be the default mode for ajc. There is at least one major space issue that needs to be resolved before that can happen. The implementation of –Xreweavable for 1.2 is straightforward. The org.aspectj.weaver.WeaverStateInfo attribute needs to be extended to have a reweavable variant. This reweavable variant will include two new field. 1. A list of the fully qualified type names for all aspects that modified the classfile during weaving. BcelClassWeaver will need some minor changes to populate this list. When reweaving, the weaver will check that all of these aspects can be found and issue an error if any are missing. 2. Enough binary information to recover the original unwoven classfile for the current classfile. An initial naïve implementation should simply include all of the bytes from the original classfiles in this slot. This is the potential major space issue. A more advanced version of this implementation should use a binary diff library to minimize the bytes required by only encoding the difference between the woven classfile and the unwoven one. In general, this diff should be very small. Some thought needs to go into making sure that this attribute works well for multiple reweaving steps. BTW – The ability to reweave classfiles opens up the possibility of some very different incremental compilation models in the command-line ant world. If this attribute goes well those should be explored in the future.
Fixed - as per Jims design. Implementation overview document in CVS: modules/docs/design-Xreweavable.doc
