cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: MountTableMatcher
Date Mon, 17 Nov 2003 16:14:10 GMT
Sylvain Wallez wrote:

> Upayavira wrote:
>> Sylvain Wallez wrote:
>>> Carsten Ziegeler wrote:
>>>>> The main samples sitemap now uses a mount table located at the 
>>>>> root of the Cocoon directory. It is not present by default (and 
>>>>> ignored silently), but a "mount-table.xml.sample" is provided that 
>>>>> just needs to be copied to "mount-table.xml".
>>>> Just one thing, why is this in cocoon root directory? Couldn't it
>>>> be in the src/webapp directory (context root)?
>>> Certainly not! The purpose of putting it in the root directory is 
>>> that it is not part of the build, and so not deleted if you do a 
>>> "build clean".
>>> Now maybe directly at the root is not a so good location and it 
>>> should be placed elswhere. But this also would mean that it's less 
>>> visible.
>> Would it be possible to make it configurable in and 
>> have it default to ../..?
>> This would, to my mind, make your solution usable in a live 
>> environment too where webapps aren't necessarily still in build/webapp.
>> I don't know if the XPatch task can handle patches with ant 
>> properties, but if it could...
> Sorry to jump in late (just saw your "I commited it!" message), but 
> what's the need for this?

I see the potential for your matcher going further than you seemed to 

My patch is aimed to allow the user to choose the location of the 
mount-table file without the need to change the root sitemap itself.

This means that the matcher can be used, without changing the root 
sitemap, with the webapp deployed somewhere other than in build/webapp, 
which is certainly my custom.

In my deployed sites, I simply add a mount right at the beginning of the 
root sitemap, which matches on "**", thus overriding anything else in 
the root sitemap (other than handle-errors, possibly).

> MountTableMatchers allows externally-defined indirections to be 
> plugged into a sitemap, and you add another level of indirection 
> through the build property.

The indirection allows the table itself to be somewhere else, yes.

> Sorry, but this really seems FS to me as I think nobody will ever 
> change the build property, but just modify the sitemap statement...

Depends. I find it frustrating to have to re-patch the sitemap every 
time I rebuild Cocoon. This way, that becomes largely unnecessary.

> Moreover, I don't understand the "live enviromnent" argument, as it's 
> not desirable at all, IMO, to deploy the main samples sitemap "as is" 
> on a live enviromnent. All the mounts it contains are either highly 
> samples-related or automounts that are dangerous in a production 
> environment.

I would build my Cocoon for deployment without the samples and would 
create my own mount table. My own mount table would, as you have already 
said, survive a clean build of Cocoon, so I see no problem here.

The major job here was to get the Ant task to be able to do patches 
using Ant properties. That is a useful feature in itself, which I think 
should stay.

Beyond that, if you and others feel that the sitemap patch is overkill, 
I'm happy to remove it and just use it on my own systems (after all, 
that is only one file on src/confpatch).

Does this explain better what I had in mind with this? For me I see it 
as useful, even in a live environment, but certainly with the samples 

Regards, Upayavira

View raw message