cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Experimental per-sitemap reloadable classloader
Date Thu, 24 Mar 2005 16:45:02 GMT
Sylvain Wallez wrote:
> 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.

The funny thing is that *all* sitemap resources how are relative to the 
trunk... maybe something to do with symlinks?

Is anybody using symlinks to mount stuff on the cocoon webapp? c'mon, I 
can't be the only one!

> 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 :
> <map:classpath>
>    <class-dir src="BLOCK-INF/classes"/>
> </map:classpath>
> 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.

Don't know why, but I've always disliked very much the mount-table.xml 

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

hmmm, but why is the sitemap now behaving as it's relative to the root 
context? puzzling.


View raw message