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 http://127.0.0.1:8888/mycocoonapp.
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
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
