RE: [aspectj-dev] RE: aop.xml exclude loader (was[aspectj-users] problem

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

Hi Matthew,

 

>> ... one of the primary uses of aop.xml files is to configure which aspects apply to which ClassLoaders.
>Nope. There is no reliable way to associate an aop.xml file exclusively with the classes defined by a particular class loader. There should be 3 >types of aop.xml file:

 

Are you saying that in theory there isn’t a general way to do this? In practice the aop.xml files are deployed with jars that are loaded by specific ClassLoaders, whether in an application server or an OSGI bundle. This is done precisely to have aspects affect given application layers (e.g., system-wide, shared across applications, within an application, within only a Web tier but not EJBs, etc.). While it might be nice for application developers to not need to know about ClassLoaders, in practice it is a requirement…

>1. Associated with an aspect or aspects. This can be generated by the tools and simply declares which aspects exist

Sure: and then where the aspect & aop.xml file is deployed governs where it applies.

>2. Associated with an application, component or set of classes. The best use case is the <concrete-aspect> element that allows you to >customize an abstract aspect. You may also add include/exclude elements in both the <aspects> and <weaver> sections but their use is >problematic at this level because they affect all classes defined in that branch of the class loader hierarchy. Typically people writing >applications either have no knowledge or desire to have knowledge of class loader hierarchies, and certainly should not have to understand >them to write and deploy an AO program which must behave the same wherever or however it is run. The expert user that does understand >how a particular platform is implemented can pragmatically use include/exclude for certain applications.

 

I think it’s fair to say that many Java programmers have insufficient knowledge of Class Loaders and hierarchies, but correct Java EE programming virtually necessitates knowledge about Class Loaders. I haven’t done much OSGI development, but I would be surprised if you can develop OSGI apps without knowledge of how class loading works.

 

When you deploy an aop.xml file, especially an additive one that might exclude aspects or classes that were included (perhaps by default) in the parent, you are typically adjusting the way aspects apply across a ClassLoader hierarchy. In many cases this is driven by performance concerns. This might be avoiding the overhead of weaving into some place, or it might be done to avoid issues with weaving into an application that was woven at build time where reweaving would require exposing more aspects to load-time weaving.

>3. Associated with the system. This can be added to the server classpath and will affect everything. It is a useful mechanism to guarantee >certain classes are not woven, request verbose messages and byte-code dumps or switch off weaving globally e.g. <aspects exclude="*"/>. It >can also be used to customize LTW for integration purposes e.g. define a message handler or perhaps IWeavingContext as suggested below.

>I don't quite understand your 2) below but it does illustrate the complexity of the J2EE environment, a situation that I don't think will be helped >by adding configuration to AspectJ that refers to it. However I do understand your concerns about performance and tailoring AspectJ to >different environments. This is why I think the IWeavingContext is the right approach.

I would be interested to understand more about how you envision IWeavingContext supporting Java EE integration, and how it might support optimizing by not weaving into lightweight child ClassLoaders, while still preserving an ability to weave into child ClassLoaders where an application’s aspect can apply…

 

Thanks,

Ron