| Re: [aspectj-users] AspectJ 1.5 aop.xml question |
|
Alexandre, Mathew, thank you very much for the feedback. I read your
comments on the bug listing (https://bugs.eclipse.org/bugs/show_bug.cgi?id=115275).
So it sounds like it makes no sense to have a
<aspects><include> element unless it is weaver wide, as
developers can just comment out the <aspect> elements that they
do not wish to include. I do have a follow up quesiton. I *think* I understand what you two mean by "weaver wide". I must admit that my knowledge of classloader hierarchies is a bit thin. By "weaver wide", do you mean that a single weaver can weave in all classes loaded by all classloaders? My understanding is that you can define an aop.xml file per classloader. By making the <aspects><exclude> element weaver wide, does that mean an aop.xml file for a child classloader can exclude aspects specified in an aop.xml file for a parent class loader? Can a child classloader disable the aspects specified for the parent classloader? Let me know if my understanding is off track. Many thanks, -Nathan Alexandre Vasseur wrote: Matthew Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=115275 Having include/exclude affects the set of aspect system wide and not just the set from the aop.xml file is usefull in some situation (debug etc) but can also be source of unknown effect (disabling aspect configured by someone else). On 11/7/05, Matthew Webster <matthew_webster@xxxxxxxxxx> wrote:Nathan, Alex is right. All aspects _must_ be known to the weaver before a single type (class, interface or even aspect) is woven or defined. There is no easy way to do this unless they are enumerated by the application owner; you would have to load every visible class and see if it was an aspect in order to implement your suggestion which would be very slow if practical. However help is close at hand because this enhancement https://bugs.eclipse.org/bugs/show_bug.cgi?id=95516 is almost complete. The include and exclude elements: <aspectj> <aspects> <include within="com.foo.security.*/> <exclude within="com.foo.transaction.*"/> <aspects/> </aspectj> are used to filter aspects inherited from the rest of the system. However you seem to have found a bug. The example above will fail. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/ Please respond to aspectj-users@xxxxxxxxxxx Sent by: aspectj-users-bounces@xxxxxxxxxxx To: aspectj-users@xxxxxxxxxxx cc: Subject: Re: [aspectj-users] AspectJ 1.5 aop.xml question afaik you need to list all the aspects you want weaved in your project. than include/exclude are used only to filter them. hth, ./alex -- .w( the_mindstorm )p. On 11/4/05, Nathan McEachen <nathan@xxxxxxxxxxxx> wrote: > I have a question about load-time weaving in AspectJ. According to the > AspectJ 5 Development Kit Developer's Notebook, the <aspects> element > can have an <include within="[pattern]"> child element > (http://eclipse.org/aspectj/doc/next/adk15notebook/ltw-configuration.html). > > However, when I include that element as a child to the <aspects> element > in my aop.xml file, I get a SAX exception: > > org.xml.sax.SAXException: Unknown element while parsing <aspectj> > element: include > > > Is the <include> element currently supported within the <aspects> > element? Or do I have to explicitly list every aspect I want woven at > load time using an <aspect name="..."> for each aspect? Basically I do > not wish to explicitly ennumerate every aspect in the aop.xml file for > the load-time weaver. Rather, I want to use a wildcard pattern to > capture them all. > > Thanks, > > -Nathan > > -- > In theory, there is no difference between theory and practice. But, in practice, there is. > > --Jan L.A. van de Snepscheut > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users_______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users -- In theory, there is no difference between theory and practice. But, in practice, there is. --Jan L.A. van de Snepscheut |