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 18:17:21 GMT
Stefano Mazzocchi wrote:

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

I checked, it works for me. I added some stronger checks that given 
paths are actual directories.

An error I made after a quick copy/paste is to have <class-dir 
src="BLOCK-INF/lib"> when this should really be *<lib-dir>*, which is 
inspected to search for *.zip and *.jar files.

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

Hmmm... could this be a problem with File.getPath() or 
File.getCanonicalPath() on symlinks?

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

Hey, we're doing it the pure Java way ;-P
And don't forget all those poor windoze users that don't know what 
symlinks are ;-)

>> 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 
> thing.

Well, just try it! :-)

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

Yup. It really shouldn't...


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

View raw message