cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Experimental per-sitemap reloadable classloader
Date Thu, 24 Mar 2005 07:46:28 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>> 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>
> Hmmm, I've used this for the first time today and I have to say that I 
> would love my cocoon application to be 'self-contained', so to speak, 
> so that I can move it around at best.
> What I've done is:
>  1) package my stuff so that it looks like a real block
>     README.txt
>     INSTALL.txt
>     sitemap.xmap <-- this is my block sitemap
>     stylesheets <-- this is the block resources
>     * <-- add other resources at will
>     src/java <-- this is the components sources
>     lib <-- this contains the jar my code depends on
>     build/eclipse <-- here is where eclipse compiles stuff
>  2) add
>     <map:classpath>
>      <class-dir src="./build/eclipse"/>
>      <lib-dir src="./lib"/>
>     </map:classpath>
>     to the sitemap above
>  3) add a symlink
>       $COCOON_HOME/build/webapp/mycocoonapp -> /code/mycocoonapp
> et voila', you are able to 'mount' stuff in cocoon without even 
> touching a single line in your cocoon installation, then you just have 
> to have your proxypass setup so that http://host/mycocoonapp points to 
> Easy, fast and secure.
> Too bad it doesn't work! since 'lib-dir' resolves the '.' in './lib' 
> as local to the cocoon context, instead of the location of the sitemap 
> it's found in.
> This is a mistake, IMO: a real block should *NOT* contain any 
> information about where it has been mounted and this behavior requires 
> it to do so, preventing the block to be mounted somewhere else 
> transparently.
> Is there any need for this behavior that I didn't consider?

I will check the lib problem. If it behaves as you state, this is 
clearly a bug.

I've been using the per-classpath feature extensively lately, but 
without additional libs (just a class-dir), and it works like a charm. 
What a productivity boost!

Here's my classpath declaration :

    <class-dir src="BLOCK-INF/classes"/>

IMO the name "eclipse" should not appear, as the contents of the classes 
dir can be generated equally by saving your file in Eclipse or running 
an Ant build (I use both). My sample was the first layout I used, but I 
quickly changed to self-contained mini-apps as you describe. I think in 
a near future we'll have a "src-dir" configuration as well using the 
compiling classloader.

Also, I don't use symlinks in build/webapp that can be destroyed by a 
build clean, but use the mount-table matcher. Copy 
mount-table.xml.sample in the main Cocoon dir to mount-table.xml and 
mount your external mini-apps there.

The only thing missing is the automatic reload of classes (you still 
need to touch the sitemap, which I sometimes forget), but other than 
this minor annoyance, what a pleasure!


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message