cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Experimental per-sitemap reloadable classloader
Date Wed, 09 Mar 2005 14:33:09 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> 
>>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 "../..").
>><map:components>
>>  <map:classpath>
>>    <class-dir src="../../build/eclipse"/>
>>    <lib-dir src="../../lib"/>
>>  </map:classpath>
>>  <!-- other components -->
>></map: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 
>>mode.
>>
>>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.
>>
> 
> Great!!
> 
> What about using this for blocks - a simple version - as well? So we
> could just drop a block of functionality (or a web app) into Cocoon. The
> sitemap has the includes for the components and this extra classpath.
> 
> For reloading: when the sitemap is reloaded, the classloader could only
> reload those classes/jars that have changed since the last load/reload.
> 
> WDYT?

I was thinking about the exact same thing :-)

Boy, without even planning, we got closer and closer (incrementally) to 
real blocks.

-- 
Stefano.


Mime
View raw message