Community
Participate
Working Groups
LTW can be used in a development environment when the JVM is run under the debugger. If a class is modified it may be recompiled, submitted to the JVM being debugged and "HotSwapped" (see bug 117854). The AspectJ 5 javaagent used for LTW is made aware of this through the JVMTI (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/ClassFileTransformer.html) but current implementation throws an exception. There may be a limited number of transformations we could safely perfrom especially if the aspects involved only implement dynamic cross-cutting.
Hi guys! I saw that the AspectJ5 release is out ... Congratulations and Thanks! :) Now, can you please give this issue a priority? It's really important to us. Thanks! Misha.
Some thoughts on how we go about implementing this. Firstly this can't be "run-time weaving by the back door". There are several restrictions current production JVMs place on what you can do to class at runtime (see http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg05170.html). This enhancement should be considered an improvement to the support for LTW in a debug environment. Secondly we may need to limit support (at least initially) to include only just classes. Swapping an aspect would require enumerating and reweaving all previously loaded classes unless we can borrow some logic from an improved incremental compilation mechanism. This is because for LTW classes and aspects will typically be built separately and hence not automatically submitted by the debugging JVM. Finally the key problem that I see is to ensure a class is resolved using the new unwoven bytes rather than from disk (or anywhere else) using ClassLoader.getResource() as usual. This may need a new route into the weaving or “forcing” the new bytes into the World. Writing testcases is going to be fun!
"... Secondly we may need to limit support (at least initially) to include only just classes. Swapping an aspect would require enumerating and reweaving all previously loaded classes unless we can borrow some logic from an improved incremental compilation mechanism ... " 1. I totally agree. This feature looks like "for debugging only". It'll make A LOT of programmers happy, because honestly, iajc has terrible performance and a huge memory footprint. It makes windows desktops go crazy, and programmers to make themselves a cup of coffee ;-) 2. "... from an improved incremental compilation mechanism ..." - What do you mean? Daemon that monitors and rebuilds only affected classes/aspects? We've tried to work with it, it looked totally unstable ... This is why this feature is so important to us. If you need any help testing stuff on a BIG development project, feel free to use us. Thanks! Misha.
Given the amount of investigation required and problems with test this won't make 1.5.3.
I want this feature too! :) And if you need some help testing on a large project, please use me too. And btw which version of aspectj may include this feature?
Might it be possible as an interim fix to just not throw an exception, but log a warning instead? This would of course leave it up to the developer to keep track of invalidating their runtime, but in certain scenarios I believe that would be totally possible. As an example case I just started using LTW for Spring transaction advice of Struts Actions. (I can't use their proxy based AOP because Struts MappingDispatchAction.execute(...) does a this.x(...), which bypasses the proxy.) Now during development any class I touch, whether it's advised or not, causes HotSwap to fail. The requisite server restarts drain enough time that I'm considering punting on LTW. If I only had to restart when modifying one of my known declared transaction points that would certainly be manageable.
Created attachment 98340 [details] patch class to change ltw of redefined classes Do you mean this exception? AspectJ5 does not weave hotswapped class I presume you aren't really asking for this to be downgraded to a warning, because it isn't actually thrown, it is just printed out. From this code: if (classBeingRedefined == null) { return s_preProcessor.preProcess(className, bytes, loader); } else { new Exception("AspectJ5 does not weave hotswapped class (" + className + ")").printStackTrace(); return bytes; } I guess you really want is us to have-a-go at weaving rather than returning the unwoven bytes. The attached patch will attempt to reweave the class when it is redefined - you will see an exception entry printed out about this happening, but it will be woven. Try it out, you need to patch your aspectjweaver.jar with the class in here: jar -xvf patch.zip jar -uvf aspectjweaver.jar org depending on your success, I might commit something.
(In reply to comment #7) > I presume you aren't really asking for this to be downgraded to a warning, > because it isn't actually thrown, it is just printed out. From this code: So it does. Forgive me for being out of my element here. I couldn't find a source download for AspectJ, so I just presumed Eclipse's HotSwap failure dialog and the preceding stack trace in the log were closely related. After some digging I've checked out version 1.5.4 of the weaver, weaver5, loader, and loader5 modules, built and attached a source jar for aspectjweaver-1.5.4.jar, and now see exactly where you are referring too. The issue might lie with Spring then. I'm starting JBoss with: -javaagent:path/to/spring-agent-2.5.3.jar And have the following in my Spring config: <context:load-time-weaver aspectj-weaving="on" /> If I remove that config entry I no longer get the hot swap failures. I figured it was a long shot, but I applied your patch class... [snip] 21934 Thu Dec 20 13:44:18 PST 2007 org/aspectj/weaver/loadtime/ClassLoaderWeavingAdaptor.class 241 Tue Apr 29 13:52:18 PDT 2008 org/aspectj/weaver/loadtime/ClassPreProcessor.class 12697 Thu Dec 20 13:44:18 PST 2007 org/aspectj/weaver/loadtime/ConcreteAspectCodeGen.class [/snip] No change, so unfortunately until I can get hot swap working at all with Spring's load time weaver turned on I can't provide feedback on your patch. My thanks for such a quick reply however!
ok - I'll ask some spring guys, watch this space :)
Ian, What happens if you try -javaagent::path/to/aspectjweaver.jar (and remove <context:load-time-weaver aspectj-weaving="on" /> as it is no longer needed)? They both use basically the same underlying machinery, so any change in hotswap behavior should tell us something. -Ramnivas
Created attachment 100035 [details] Patch for 1.6 level weaver jar new version of patch, that last one was rubbish :)
I migrated from the Spring 2.5.3 and spring-agent with AspectJ 1.5.4 to the Spring 2.5.4 with the spring-tomcat-weaver(In reply to comment #10) > Ian, > > What happens if you try -javaagent::path/to/aspectjweaver.jar (and remove > <context:load-time-weaver aspectj-weaving="on" /> as it is no longer needed)? > They both use basically the same underlying machinery, so any change in hotswap > behavior should tell us something. > > -Ramnivas Haven't had a chance to try this yet. I switched to Spring's TomcatInstrumentableClassLoader. Hot swap is working now for the usual non-API related changes. Not getting the warning message from ClassPreProcessorAgentAdapter, and that makes sense as a quick scan of Spring's source suggests it's not used. What's not clear is whether classes swapped by TomcatInstrumentableClassLoader are being rewoven, but that seems a question for the Spring folks. So my highly uninformed guess is that the outright failure of HotSwap is unrelated to "AspectJ5 does not weave...", and is a higher up problem with the Spring Agent. If I can get a chance to build an environment with the AspectJ weaver agent and the ClassPreProcessorAgentAdapter patch I'll follow up.
(In reply to comment #12) > I migrated from the Spring 2.5.3 and spring-agent with AspectJ 1.5.4 to the > Spring 2.5.4 with the spring-tomcat-weaver(In reply to comment #10) Ignore that half-sentence at the top of my last comment. It's a fragment from a previous comment on another bug. Weird.
Hello, I installed the patch, but I still sometimes get the message "Hot code replacement failed. Timeout occured while waiting for packet XXXX". The message appears randomly, from time to time. I used the "showWeaveInfo" option in the aop.xml file and the join points displayed are the same when the error occurs and when it doesn't. Also, I turned dump on and watched the classes which were swapped. In both cases, they are the same. Finally, I tried to see if the new classes were really loaded (by choosing to continue and not restart Tomcat in the message)...and they were, as the functionality was changed. So is this just a harmless message? And when does it appear? And why? Thank you! Marius
Well the timeout message is not from AspectJ. I can imagine there are JVMTI timeouts for waiting on code to be transformed, but I can't find much information on that message or how to increase the timeout. Maybe we would need to include a native agent rather than a java one to specify a timeout value but I don't want to go down that route until I know that it would make a difference to this problem.
Created attachment 116501 [details] ajcore dump By applying the patch to AspectJ5 development build from 2008-10-29 I can hotswap weaved class. But if I want to hotswap the aspect itself, I am getting exception which is in the attached file. With this patch being not officially included in AspectJ5 I can't unfortunately use it for development and so I must revert back to Spring AOP proxying for now.
downloaded the patch, and it seems to work just fine, please advise when patch is in regular build
get this into 1.6.7
I just committed the patch into HEAD for this. AspectJ 1.6.7 builds after today will attempt reweaving. When it occurs, AspectJ will (currently) produce an INFO message: "INFO: (Enh120375): AspectJ attempting reweave of '"+className+"'" this is purely informational but if things subsequently go pear shaped, it will be a clue as to why. After a while, if we are confident in reweaving, I will remove the message.
patch is in and not aware of any further issues here right now.
no more to do here.
