Community
Participate
Working Groups
I have found this class to be quite helpful as a way of using load-time weaving to run inside an IDE. This nondelegating classloader weaves into any classes on the system classpath, making it work well as a drop in load-time weaving option with a single command -Djava.system.class.loader=org.codehaus.ajlib.util.classloader.AlwaysWeavingURLClassLoader This avoids the difficulty of changing how IDE's like IntelliJ set up their classpath. For that matter, how does the Eclipse load-time weaving configuration work? It seems like it won't weave things on the classpath either and would benefit from this class as well. It didn't allow me to weave any classes in my test project, whereas this does.
Created attachment 32066 [details] always weaving nondelegating classloader to integrate this into the code base it would be better to refactor to eliminate duplicated private methods from the WeavingURLClassLoader...
Created attachment 38055 [details] Prebuilt jar containing a compiled version of the classloader, which works with AspectJ 1.5.0 (and later I believe)
Thanks for the example, Ron. Given the AJDT support for a load-time weaving configuration, I'm not sure this is still required as an AspectJ offering (and I'm reluctant to promote nondelegating class loaders). But it does seem worth publishing for other IDE's and users; do you want to publish it yourself? Please reopen if you disagree. stalebug
I think it's still useful for two classes of users: - those using IntelliJ - those using Java < 5 (as I understand it the AJDT support for load-time weaving using -javaagent) While I agree that nondelegating classloaders have their problems, I think it'd be better to include this as part of AspectJ.
Some comments: >those using IntelliJ I don't believe we include any IDE-specific support in AspectJ (anymore) >those using Java < 5 (as I understand it the AJDT support for load-time >weaving using -javaagent) We use -Djava.system.class.loader for 1.4. There is no reliable mechanism for 1.3 >While I agree that nondelegating classloaders have their problems, ... They are an evil hack
