Community
Participate
Working Groups
Prototyped and tested for JspClassLoaders (see the thread 'aspectj and jsp load' on the mailing list). That was done through a system property but it would be easier via aop.xml. However, this would be the first time we have an aop.xml setting that affects global operation of loadtime weaving. When any classloader actually got far enough to load the aop.xmls it would discover this setting and from that point on it would be set. In our JspClassLoader case this would mean that either some non-JspClassLoader is run early enough to discover this setting and turn it off for all JspClassLoaders or the first JspClassLoader will discover the setting and turn it off for all other JspClassLoaders. I think we can live with that mode of operation.
unsetting the target field which is currently set for something already released
Pushed this into the 1.7 branch (so will be in the 1.7.4 release). Two config mechanics: 1) System property, comma separated list of classnames: aj.weaving.loadersToSkip=com.foo.MyLoader,com.bar.SomeOtherLoader 2) aop.xml, in the options value: -loadersToSkip:com.foo.MyLoader,com.bar.SomeOtherLoader The former has had more testing than the latter. If anyone tries this out let me know if the 2nd option is behaving. As the aop.xml files are read *after* the weaver is initialized it is possible that (currently) the first loader of the type will get through, and only subsequent ones will not get a weaver. In a situation where you want to exclude 5000 Jsp loaders, if just 1 gets through that doesn't feel like a big deal, but this loophole should be closed later.
