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 }
|