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.



Reply via email to