Re: [aspectj-dev] "noweave" use case

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

-Xnoweave is an experimental option; it comes with no guarantees
(except that we know enough about it not to trust it!).  

One of the conditions for load-time weaving is to have the aspects 
completely resolved in the aspectpath before any classes are loaded.
Aspects in the aspectpath do not weave into each other (unless they
were compiled together).  So I don't think the weaver supports 
weaving two aspects into each other when used for class loading.

Wes

Martin Lippert wrote:
> 
> Hi,
> 
> just a short question that comes to my mind when I read your discussion
> about -noweave. In my prototype of an AspectJ-enabled Eclipse Runtime I
> currently compile the plugins that contain aspects with the -noweave option.
> I am not quite sure if this is the right way to go for my purpose. But
> in my case plugins contain code that is compiled (with or without
> aspects). Then the runtime weaves the aspects into the classes that are
> loaded. Therefore it might happen that two plugins provide two different
> aspects. The weaving might need to weave both aspects into each others
> plugin, for example.
> 
> What do you think of this? Is the -noweave option the right way to go?
> Or do we need something new?
> 
> Best regards,
> Martin
> 
> Wes Isberg wrote:
> > Hi Ram -
> >
> > 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
> >>
> >>__________________________________________________
> >>Do you Yahoo!?
> >>Yahoo! Tax Center - File online, calculators, forms, and more
> >>http://tax.yahoo.com
> >>_______________________________________________
> >>aspectj-dev mailing list
> >>aspectj-dev@xxxxxxxxxxx
> >>http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev