Torsten Curdt wrote:
A side benefit, tremedously useful, is that the classloader is re-created when the sitemap is reloaded. So this allows, by setting a class-dir, to reload changed classes simply by touching the sitemap.
Awesome, mate! :-D
If we integrate the file alteration monitor from jci we can even trigger the sitemap reload without the need of touching the sitemap.
...and we could also hook in the byte code transformations (if needed ..like for javaflow)
Do you think that would work?
The classloader is created by a factory that is looked up using o.a.c.Core.ClassLoaderFactory, given the <map:classpath> configuration object (see in src/java/core). So by defining this component in the root cocoon.xconf, we can plug in any classloader strategy we want.
What's missing however, is the notification link between the classloader and the sitemap engine, in order to trigger reloading. That's something that should be fairly easy to add.
Maybe not as smart as an automatic compiling classloader, but as saving
...not sure if it really has to be a compiling classloader as long as we have a automated reloading from within the ide.
Yep, you're right. It only has a drawback for the vi or emacs addicts ;-)
This feature is intended for application development-time, as it doesn't take into consideration instances of the previous versions of the reloaded classes that may be stored here and there such as in session attributes. That means that you may get some ClassCastException whenever such a cases arises. This is the current price to pay for fast roundtrips.
I think that's ok for development!
Overnight (the brain is a non-stop machine) I found a scheme that could avoid this session-attribute annoyance: we can automatically invalidate sessions that have been created before the classloader creation. When a local classloader is created somewhere within Cocoon, a timestamp is stored in a global Context attribute. When a request comes in, we invalidate the session (if it exists) if it was created before the last classloader creation. HttpSession.getCreationTime() gives us the necessary information for this.
Great stuff!
Thanks! Not that complicated though: I added the handling of <classpath> in CoreServiceManager and reused some parts of the paranoid block. A 2-hours hacking session to save a lot of time :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
