cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Experimental per-sitemap reloadable classloader
Date Tue, 08 Mar 2005 22:52:14 GMT
Hi all,

Having to often write quick prototypes with Cocoon, I have on my laptop 
one main Cocoon installation and a lot of subsitemap directories in 
various locations, all mounted into the main Cocoon using the 
mount-table matcher.

That works fine until the prototypes need some specific classes, as I 
then hit the problem of deploying these classes. Some ant tasks 
automatically copy the corresponding jars in the main WEB-INF/lib, but 
that's really not convenient.

So I wrote in 2.2 an experimental per-sitemap classpath that allows each 
sitemap to define its own specific classpath for the components defined 
by <map:components>.

The syntax is as follows (the sitemap is in src/webapp hence the "../..").
    <class-dir src="../../build/eclipse"/>
    <lib-dir src="../../lib"/>
  <!-- other components -->

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.

Maybe not as smart as an automatic compiling classloader, but as saving 
in Eclipse automatically recompiles the classes, the productivity boost 
is impressive, especially when combined with the component lazy-loading 

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.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message