Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] "noweave" use case 
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

Back to the top