Community
Participate
Working Groups
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.
note: aspects/include and aspects/exclude only affect the set of aspects declared in this aop.xml file discussion needed to allow further side effect (usefull to debug but quite dangerous as could lead to unknow deactivation of aspects configured by someone else). doc updated accordingly
This implementation is pointless. The user can easily determine which aspects declared or defined locally are _actually_ used by commenting out or deleting the relevant entries. It is also contrary to the intent of the agreed specification. In a large system it may be necessary to quickly and easily disable one or more aspects globally. This change makes that impossible. Certainly in a classloader hierarchy the careless use of an include/exclude aspects sub-element can cause LTW to be disabled at a lower level. However the same applies to include/exclude for weaver sub-elements. With this implementation the user _cannot_ prevent a concrete aspect somewhere in the system effecting their application without tracking it down and removing its declaration/definition or changing its implementation. Removing the declaration/definition may have an undesirable effect on other applications and changing the implementation may be difficult or impossible especially if it is 3rd party code. We need to discuss this further before simply changing the specification.
Don't forget that weaver/include and weaver/exclude are weaver wide and can thus be used for "prevent a concrete aspect somewhere in the system effecting their application". The tradeoff here is: - if using weaver/exclude, the user CAN prevent some concrete aspect somewhere, but also prevent all other aspects to apply to its application - and in that case this fact is well know. This is implemented. - if using (not implemented weaver wide) aspect/exclude the user can also prevent that but also MAY trigger side effects on other parts of the system - and in that case this fact cannot be well know unless the user has complete knowledge on which aspects applied to where - which is not the intented approach of a classloader tied load time weaver. Note I am not changing the ""spec"". Obviously I had some issues regarding this since I had a bunch of TODO/FIXME/TBD left around that in the DTD and in the code and some emails/communication has probably beeing lost in the whole set of things discussed/implemented/prioritized - and I certainly agree the non weaver wide implementation is just useless. For this feature to happen - there is a need of a JVM wide flag to allow such behavior (-D...allowAspectIncludeExclude), else it is an easy way to simply kick out AspectJ aspects which certainly won't help much in troubleshooting (use showWeaveInfo, or -verbose & co will help much more ie if one suspects an aspect to be guilty, -verbose etc will help spot it and weaver/exclude will help isolate the user application from it) Even with this option I don't feel comfortable. I can't see any real scenario that cannot be addressed by weaver/include/exclude instead. - there is a need to change the impl quite heavily as it requires aop.xml' aspect to be actually registered only when ALL aop.xml's of the current classloader visibility level have been parsed.
Matthew made me realized that I was wrong. Sorry for the confusion We do allow an aspects'include/exclude to affect the list of aspects declared to be used in sub-deployment ie a parent deployed unit can possibly take full control and dissallow all aspects in the system/ear/war/ etc (put aop.xml <aspects><exclude within="*..*"/></aspects>) What was missing was some bits of the implementation. The thing is that given a classloader C we build an adaptor WA. WA is build by aggregation of all visible aop.xml files higher up in the hierarchy. Then we build the weaver and its world. Hence at the end of the parsing we indeed have all the include/exclude elements to accept aspects. Next we need to decide if we want to issue a message or something that would help understand why the thing you deploy is not weaved - f.e. if someone higher up is using a "<aspects><include>" that does not match our aspect bundled in the deployed unit. Ideally some verbose mode that reports 'type X not exposed to the weaver due to ....path..to..aop.xml [include|exclude] ....pattern....' and 'aspect A not registered due to ....path..to..aop.xml [include|exclude] ....pattern....'
Created attachment 29688 [details] Use case for <aspects><include> An application may inherit one or more concrete aspects from the platform on which it runs e.g. Tomcat. These may relate to problem diagnosis, profiling or some other platform feature. The application author/deployer needs to be able to select which aspects are actually used without having to modify the aspect the source code to which they may not have access.
Created attachment 29958 [details] Testcases and fix 1. Lint warning issued when aspect not included for weaving 2. Testcase for warning
patch integrated.
matthews fix now available.
