RE: MountTableMatcher ending slash
Sylvain Wallez wrote:
>
>
> ?? The use of the mount table doesn't change the
> semantics, and if the mount occurs, there's no turning back
> to the parent sitemap.
>
> >The change claims:
> > // Append a '/' at the end of the prefix
> > // this avoids flat uri matching which would cause
> > // exceptions in the sub sitemap!
> >I was not getting exceptions like this in 2.1.4...could
> anyone explain
> >in more detail the reasons for this change?
> >
> >
>
> Yep. Carsten (you did this patch)?
>
Yes, I feel guilty...the reason for the patch was, I had severe
problems with the following:
Now, if I use the url "cocoon/woody-samples" the request is passed
to the subsitemap and did cause exceptions there ("The current URI
(woody-samples) doesn't start with given prefix (woody-samples/)).
Then I thought about this issue and had the impression that a
request with "cocoon/woody-samples" should not go to the
subsitemap. Only a request a la "cocoon/woody-samples/" should
go there.
> >
> > We could have a passthru="true" attribute on map:mount's to
> > turn on pass through behaviour...
> >
> >
> >
>
> The mount table uses the exact same syntax as
> where no slash is automagically added. This allows mounts to
> occur in the same directory of the URL space.
>
> So IMO, the right solution is to assume the user has properly
> written the prefix, and therefore revert this modification.
>
> WDYT?
>
I'm not sure :) If you use a mount, you have a match before, like
you explicitly take care that
the uri has an ending slash.
If you do:
and call "localhost/samples", you get the same exception
"The current URI (samples) doesn't start with given prefix (samples/)"
Carsten
Re: MountTableMatcher ending slash
Tim Larson wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=107831750602134&w=2
src/java/org/apache/cocoon/matching/MountTableMatcher.java
Log: Add an ending slash to the prefix
I just realized this change caused a loss of functionality that I
was planning to use. A mount-table is a pass-through construct:
if no match is found by following the mount-table, then the search
is continued in the sitemap that mounted the mount-table file.
Right: it's "just" a matcher, and as such if no prefix matched sitemap
execution continues
A normal map:mount is not pass-through: if no match is found in the
mounted sitemap, then the search is ended.
Right: a sitemap *must* handle a request it is given. If no pipeline is
built by a sitemap, a ResourceNotFoundException is raised.
With this change from 2.1.4 behaviour we lose the ability to setup
pass-through behaviour by mapping a sub-sitemap into the same url
space as its parent and letting the parent match what the sub-sitemap
does not match.
?? The use of the mount table doesn't change the semantics,
and if the mount occurs, there's no turning back to the parent sitemap.
The change claims:
// Append a '/' at the end of the prefix
// this avoids flat uri matching which would cause
// exceptions in the sub sitemap!
I was not getting exceptions like this in 2.1.4...could anyone
explain in more detail the reasons for this change?
Yep. Carsten (you did this patch)?
We could have a passthru="true" attribute on map:mount's to
turn on pass through behaviour...
The mount table uses the exact same syntax as where no slash
is automagically added. This allows mounts to occur in the same
directory of the URL space.
So IMO, the right solution is to assume the user has properly written
the prefix, and therefore revert this modification.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Starting CTP (was: Re: MountTableMatcher)
Giacomo Pati wrote: > > Unico Hommes wrote: > > > > I started on a Maven plugin > > for cocoon some time ago exactly for this reason. But unfortunately > > haven't been able to work on it lately. Maybe something for CTP if > > that would prove to take off. > > We already have such Maven plugins and if CTP will start we > sure will contribute. > It seems I'm going to dedicate some time to further this plugin. How can we coordinate this effort best? I can continue with my own effort or we can decide to join forces now and find some place to host Giacomo's Maven plugin. How do people feel about David Crossley's proposal of using the cocoon-2.1 repository to get started on this? Regards, Unico
Re: XConfPath task (was Re: MountTableMatcher)
Upayavira wrote: Vadim Gritsenko wrote: Geoff Howard wrote: Upayavira wrote: ... We could: (1) Remove the replace-properties attribute, and replace properties automatically in the content, and in the top level attributes. (2) Leave the replace-properties attribute, and only replace properties in the top level attributes if it is set to true. How about (3) default replace-properties to true, and make it optional. If someone comes up with some valid reason that variable replacement should be turned off, they can. That's what is called "FS" around here ;-) So, Vadim, you'd say 'replace properties always', and if someone wants to switch replacement off, they can code the patch task so that it doesn't. I.e. add the functionality when it is needed, not when we can think of it. Am I right? Yes, you are right. That's what we are following, more or less: add functionality when there is a valid use case for it. And if nobody can think of use case - then why to have this functionality? :) Vadim
Re: XConfPath task (was Re: MountTableMatcher)
Jeremy Quinn wrote:
On 21 Nov 2003, at 15:04, Geoff Howard wrote:
Vadim Gritsenko wrote:
Geoff Howard wrote:
Upayavira wrote:
...
We could:
(1) Remove the replace-properties attribute, and replace
properties automatically in the content, and in the top level
attributes.
(2) Leave the replace-properties attribute, and only replace
properties in the top level attributes if it is set to true.
How about (3) default replace-properties to true, and make it
optional.
If someone comes up with some valid reason that variable
replacement should be turned off, they can.
That's what is called "FS" around here ;-)
Except that in this case it's already coded! We're talking about
whether we should remove the existing ability to turn off this new
feature.
Ok, I shouldn't have made what I consider a current plausibility to
sound so hypothetical. There are patches which may need to handle
${xxx} style data (like Jexl expressions which are meant to be
evaluated at runtime, not at build time). Xpatch would screw these
up if not allowed to turn off this feature. This will be rare, so I
proposed the option (3) above to preserve the ability but not cloud
normal usage.
Jexl yeah, sorry did not think of that
regards Jeremy
It is now implemented - no time to test though for the moment
Regards, Upayavira
Re: XConfPath task (was Re: MountTableMatcher)
On 21 Nov 2003, at 15:04, Geoff Howard wrote:
Vadim Gritsenko wrote:
Geoff Howard wrote:
Upayavira wrote:
...
We could:
(1) Remove the replace-properties attribute, and replace properties
automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace
properties in the top level attributes if it is set to true.
How about (3) default replace-properties to true, and make it
optional.
If someone comes up with some valid reason that variable replacement
should be turned off, they can.
That's what is called "FS" around here ;-)
Except that in this case it's already coded! We're talking about
whether we should remove the existing ability to turn off this new
feature.
Ok, I shouldn't have made what I consider a current plausibility to
sound so hypothetical. There are patches which may need to handle
${xxx} style data (like Jexl expressions which are meant to be
evaluated at runtime, not at build time). Xpatch would screw these up
if not allowed to turn off this feature. This will be rare, so I
proposed the option (3) above to preserve the ability but not cloud
normal usage.
Jexl yeah, sorry did not think of that
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: XConfPath task (was Re: MountTableMatcher)
Vadim Gritsenko wrote:
Geoff Howard wrote:
Upayavira wrote:
...
We could:
(1) Remove the replace-properties attribute, and replace properties
automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace
properties in the top level attributes if it is set to true.
How about (3) default replace-properties to true, and make it optional.
If someone comes up with some valid reason that variable replacement
should be turned off, they can.
That's what is called "FS" around here ;-)
Except that in this case it's already coded! We're talking about
whether we should remove the existing ability to turn off this new feature.
Ok, I shouldn't have made what I consider a current plausibility to
sound so hypothetical. There are patches which may need to handle
${xxx} style data (like Jexl expressions which are meant to be evaluated
at runtime, not at build time). Xpatch would screw these up if not
allowed to turn off this feature. This will be rare, so I proposed the
option (3) above to preserve the ability but not cloud normal usage.
Geoff
Re: XConfPath task (was Re: MountTableMatcher)
Vadim Gritsenko wrote: Geoff Howard wrote: Upayavira wrote: Jeremy Quinn wrote: On 19 Nov 2003, at 18:37, Upayavira wrote: ... Thanks Upayavira Did you read the bit earlier about the scheme having a flaw because of no variable substitution in the tag's attributes? No I didn't. How difficult would it be to add this? Coding-wise, pretty trivial, just wrap each string with getProject().replaceProperties(). Before we do this, I think we should sort out a few details, following on from a comment from Vadim. Do we want to automatically replace properties, and remove the replace-properties attribute? Are there any situations in which this could cause a problem? Similarly, are there any situations in which it could cause a problem in the top level attributes, e.g. xpath, or include-before? We could: (1) Remove the replace-properties attribute, and replace properties automatically in the content, and in the top level attributes. (2) Leave the replace-properties attribute, and only replace properties in the top level attributes if it is set to true. How about (3) default replace-properties to true, and make it optional. If someone comes up with some valid reason that variable replacement should be turned off, they can. That's what is called "FS" around here ;-) So, Vadim, you'd say 'replace properties always', and if someone wants to switch replacement off, they can code the patch task so that it doesn't. I.e. add the functionality when it is needed, not when we can think of it. Am I right? Upayavira
Re: XConfPath task (was Re: MountTableMatcher)
Geoff Howard wrote: Upayavira wrote: Jeremy Quinn wrote: On 19 Nov 2003, at 18:37, Upayavira wrote: ... Thanks Upayavira Did you read the bit earlier about the scheme having a flaw because of no variable substitution in the tag's attributes? No I didn't. How difficult would it be to add this? Coding-wise, pretty trivial, just wrap each string with getProject().replaceProperties(). Before we do this, I think we should sort out a few details, following on from a comment from Vadim. Do we want to automatically replace properties, and remove the replace-properties attribute? Are there any situations in which this could cause a problem? Similarly, are there any situations in which it could cause a problem in the top level attributes, e.g. xpath, or include-before? We could: (1) Remove the replace-properties attribute, and replace properties automatically in the content, and in the top level attributes. (2) Leave the replace-properties attribute, and only replace properties in the top level attributes if it is set to true. How about (3) default replace-properties to true, and make it optional. If someone comes up with some valid reason that variable replacement should be turned off, they can. That's what is called "FS" around here ;-) Vadim
Re: XConfPath task (was Re: MountTableMatcher)
Upayavira wrote: Jeremy Quinn wrote: On 19 Nov 2003, at 18:37, Upayavira wrote: ... Thanks Upayavira Did you read the bit earlier about the scheme having a flaw because of no variable substitution in the tag's attributes? No I didn't. How difficult would it be to add this? Coding-wise, pretty trivial, just wrap each string with getProject().replaceProperties(). Before we do this, I think we should sort out a few details, following on from a comment from Vadim. Do we want to automatically replace properties, and remove the replace-properties attribute? Are there any situations in which this could cause a problem? Similarly, are there any situations in which it could cause a problem in the top level attributes, e.g. xpath, or include-before? We could: (1) Remove the replace-properties attribute, and replace properties automatically in the content, and in the top level attributes. (2) Leave the replace-properties attribute, and only replace properties in the top level attributes if it is set to true. How about (3) default replace-properties to true, and make it optional. If someone comes up with some valid reason that variable replacement should be turned off, they can. Geoff
Re: XConfPath task (was Re: MountTableMatcher)
On 20 Nov 2003, at 09:59, Upayavira wrote:
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because
of no variable substitution in the tag's attributes?
No I didn't.
How difficult would it be to add this?
Coding-wise, pretty trivial, just wrap each string with
getProject().replaceProperties().
cool
Before we do this, I think we should sort out a few details, following
on from a comment from Vadim.
OK
Do we want to automatically replace properties, and remove the
replace-properties attribute? Are there any situations in which this
could cause a problem?
Not that I can think of
Similarly, are there any situations in which it could cause a problem
in the top level attributes, e.g. xpath, or include-before?
Again, I cannot think of any
We could:
(1) Remove the replace-properties attribute, and replace properties
automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace
properties in the top level attributes if it is set to true.
There are other options, but these two make the most sense. What do
people think?
I personally go for option 1.
Who is going to need a string like "${variable.name}" as *data* in
their patch files?
It does not resemble anything in a normal sitemap etc.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
RE: MountTableMatcher
Jeremy Quinn wrote:
>
> On 19 Nov 2003, at 18:37, Upayavira wrote:
>
> > Jeremy,
> >
> > Splendid article. Stuff I've been thinking about a lot recently too.
> >
> > Just one useful quote from the Ant manual:
> >
> >
> >
> >
> >
> > With this, you can get at ${env.COCOON_HOME}, etc.
>
> Thanks Upayavira
>
> Did you read the bit earlier about the scheme having a flaw
> because of no variable substitution in the tag's attributes?
>
What I do is that I copy the xmap patch file to a temporary build
directory using filtering to substitute the variables and then run the
xpatch task with it.
Unico
XConfPath task (was Re: MountTableMatcher)
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because of
no variable substitution in the tag's attributes?
No I didn't.
How difficult would it be to add this?
Coding-wise, pretty trivial, just wrap each string with
getProject().replaceProperties().
Before we do this, I think we should sort out a few details, following
on from a comment from Vadim.
Do we want to automatically replace properties, and remove the
replace-properties attribute? Are there any situations in which this
could cause a problem?
Similarly, are there any situations in which it could cause a problem in
the top level attributes, e.g. xpath, or include-before?
We could:
(1) Remove the replace-properties attribute, and replace properties
automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace properties
in the top level attributes if it is set to true.
There are other options, but these two make the most sense. What do
people think?
Regards, Upayavira
Re: MountTableMatcher
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because of
no variable substitution in the tag's attributes?
How difficult would it be to add this?
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
RE: MountTableMatcher
Giacomo Pati wrote > > Unico Hommes wrote: > > Nice article! > > > > We do basically the same thing. Note that with > MountTableMatcher you > > no longer need to patch the cocoon root sitemap. > > Why people often say so? There is no need to patch the root sitemap > anyway as it is simply trying to mount whatever comes in as > request URL > on to the filesystem. Just deploy you app as a subdirectory of the > webadd directory of Cocoon. Sure, if you need to have your > start URL to > be the root just copy a different welcome.xml/welcome.xslt over. > When developing a site - sitemap, stylesheets, templates, etc. - I find that having to copy these each time just in order to test them is a PITA. If you decide to develop inside the webapp directory to later copy them back into the projects source tree, well this has major drawback IMO. You run the risk of losing work when you do a build clean, and there's the extra step of copying the sources back into your project's source tree. > > It is too bad that Ant does not itself support a pluggable > > architecture. Now you end up replicating such a build > environment in > > every new project. > > Use another one instead (Maven, Centipede) that has 'plugins'. > > > If something changes in cocoon that impacts the build > system you need > > to update all those separate instances. I started on a Maven plugin > > for cocoon some time ago exactly for this reason. But unfortunately > > haven't been able to work on it lately. Maybe something for CTP if > > that would prove to take off. > > We already have such Maven plugins and if CTP will start we sure will > contribute. > Cool! Unico
Re: MountTableMatcher
Unico Hommes wrote: Nice article! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. Why people often say so? There is no need to patch the root sitemap anyway as it is simply trying to mount whatever comes in as request URL on to the filesystem. Just deploy you app as a subdirectory of the webadd directory of Cocoon. Sure, if you need to have your start URL to be the root just copy a different welcome.xml/welcome.xslt over. It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. Use another one instead (Maven, Centipede) that has 'plugins'. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. We already have such Maven plugins and if CTP will start we sure will contribute. Regards, Unico -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: woensdag 19 november 2003 16:41 To: [EMAIL PROTECTED] On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little "building" of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here:We've never ha http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: MountTableMatcher
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
With this, you can get at ${env.COCOON_HOME}, etc.
Regards, Upayavira
Jeremy Quinn wrote:
On 17 Nov 2003, at 23:03, Geoff Howard wrote:
Interesting. I'd rather integrate my build into Cocoon's, rather
than the other way around, and now I can see that all I've got to do
is stick files into a confpatch folder, which is really great.
Sure, but some people prefer to integrate Cocoon into their build -
and generally want to do so with as little "building" of Cocoon as
possible. Either way works well.
With this recent change to XConfPatchTask, I have been able to
refactor the way we build our Projects 'into' Cocoon.
I attempt to describe the process here:
http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding
HTH
regards Jeremy
Re: MountTableMatcher
On 19 Nov 2003, at 17:17, Sylvain Wallez wrote: Jeremy Quinn wrote: We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. It was a toss-up between patching the root sitemap, or patching the mount-table.xml ;) Do you need to patch mount-table.xml? This file is not stored in the CVS and is not in build/ and therefore isn't impacted neither by "cvs update" nor "build clean". It contains an absolute path to where this particular developer had kept their copy of the project. So AFAIU, amongst our small group, yes we do need to patch it. Unfortunately I have found a flaw in my scheme . This patch does not work properly (it writes every time), because Variable expansion does not happen in the 'xmap' tag itself (in the 'unless' attribute) : regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: MountTableMatcher
Jeremy Quinn wrote:
We do basically the same thing. Note that with MountTableMatcher you no
longer need to patch the cocoon root sitemap.
It was a toss-up between patching the root sitemap, or patching the
mount-table.xml ;)
Do you need to patch mount-table.xml? This file is not stored in the CVS
and is not in build/ and therefore isn't impacted neither by "cvs
update" nor "build clean".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: MountTableMatcher
Unico Hommes wrote: It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. Doesn't Ant 1.6 (now in beta 2 IIUC) provide for this? I think we looked at introducing some external extensions sort of along those lines for dealing with blocks build but decided it was sufficient to wait for ant's next release. My memory is fuzzy on this though. Geoff
Re: MountTableMatcher
On 19 Nov 2003, at 16:19, Unico Hommes wrote: Nice article! Thanks Unico ! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. It was a toss-up between patching the root sitemap, or patching the mount-table.xml ;) Basically I still needed the same dynamic parameters from the users environment It is too bad that Ant does not itself support a pluggable architecture. Too true Now you end up replicating such a build environment in every new project. If something changes in cocoon that impacts the build system you need to update all those separate instances. exactly I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. interesting ... I have done very little with Maven ... regards Jeremy -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: woensdag 19 november 2003 16:41 To: [EMAIL PROTECTED] On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little "building" of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here: http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
RE: MountTableMatcher
Nice article! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. Regards, Unico > > -Original Message- > From: Jeremy Quinn [mailto:[EMAIL PROTECTED] > Sent: woensdag 19 november 2003 16:41 > To: [EMAIL PROTECTED] > > > On 17 Nov 2003, at 23:03, Geoff Howard wrote: > > >> > >> Interesting. I'd rather integrate my build into Cocoon's, > rather than > >> the other way around, and now I can see that all I've got to do is > >> stick files into a confpatch folder, which is really great. > > > > > > Sure, but some people prefer to integrate Cocoon into their build - > > and generally want to do so with as little "building" of Cocoon as > > possible. Either way works well. > > > > > > With this recent change to XConfPatchTask, I have been able > to refactor the way we build our Projects 'into' Cocoon. > > I attempt to describe the process here: > > http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding > > HTH > > regards Jeremy
Re: MountTableMatcher
On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little "building" of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here: http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: MountTableMatcher
Upayavira wrote: Geoff Howard wrote: ... I haven't looked at the issues involved with the MountTableMatcher, but I've been wanting this ability in the Ant task for a while. Well, you've got it now! 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). It also seems like this can be done pretty easily with a separate conf patch file - to patch the patch so to speak. That's how I did it. I put mount-table.xmap into src/confpatch. Also remember that the conf patch target can be run standalone - no need to re-run the whole build just to patch a few conf files. Also, the location of the patches is itself configurable - this makes integrating the task into your own build easier. Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little "building" of Cocoon as possible. Either way works well. Geoff
Re: MountTableMatcher
Sylvain Wallez wrote: ... Ok, I understand your use case, and I realize that I underestimated the unsefulness of xconftask outside of Cocoon's build environment. So let's keep it there, and sorry for ranting :-/ Thank you, you're welcome! Oh, and thank you for your MountTableMatcher! Regards, Upayavira
Re: MountTableMatcher
Geoff Howard wrote: ... I haven't looked at the issues involved with the MountTableMatcher, but I've been wanting this ability in the Ant task for a while. Well, you've got it now! 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). It also seems like this can be done pretty easily with a separate conf patch file - to patch the patch so to speak. That's how I did it. I put mount-table.xmap into src/confpatch. Also remember that the conf patch target can be run standalone - no need to re-run the whole build just to patch a few conf files. Also, the location of the patches is itself configurable - this makes integrating the task into your own build easier. Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Regards, Upayavira
Re: MountTableMatcher
Upayavira wrote:
Sylvain Wallez wrote:
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
envision.
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.
This feature is definitely useful.
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
excluded.
Ok, I understand your use case, and I realize that I underestimated the
unsefulness of xconftask outside of Cocoon's build environment.
So let's keep it there, and sorry for ranting :-/
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: MountTableMatcher
Upayavira wrote: Sylvain Wallez wrote: Would it be possible to make it configurable in build.properties 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? ... 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. I haven't looked at the issues involved with the MountTableMatcher, but I've been wanting this ability in the Ant task for a while. 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). It also seems like this can be done pretty easily with a separate conf patch file - to patch the patch so to speak. Also remember that the conf patch target can be run standalone - no need to re-run the whole build just to patch a few conf files. Also, the location of the patches is itself configurable - this makes integrating the task into your own build easier. Geoff
Re: MountTableMatcher
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 build.properties 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 envision. 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 excluded. Regards, Upayavira
Re: MountTableMatcher
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 build.properties 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?
MountTableMatchers allows externally-defined indirections to be plugged
into a sitemap, and you add another level of indirection through the
build property.
Sorry, but this really seems FS to me as I think nobody will ever change
the build property, but just modify the sitemap statement...
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: MountTableMatcher
I've just committed a change so that the mount-table matcher now gets
its file from the build.properties file (or local.build.properties).
The only bit I wasn't satisfied with is the process of locating where to
patch. I would rather put a node into the
sitemap, and replace that, but there isn't an option in the xconf task
to replace a node, so I simply put it after the pattern="api/**"
matcher. Not ideal, but it works.
Please feel free to tidy up anything I got wrong.
Regards, Upayavira
Upayavira wrote:
After this bit of code turned up, I couldn't resist giving it a go.
I now have a XConfToolTask that will replace properties if
replace-properties in the top level element is set to true.
All I've now got to do is work out how to get the task to act on the
root sitemap in all circumstances. So, some digging into the build
process is required.
Regards, Upayavira
Upayavira wrote:
Just had an offer of the following code over at ant-dev, which should
do it nicely (came with an 'untested' disclaimer though).
public void replaceProperties(Node n) throws DOMException {
switch (n.getNodeType()) {
case Node.ATTR_NODE:
case Node.CDATA_SECTION_NODE:
case Node.TEXT_NODE: {
n.setValue(getProject().replaceProperties(n.getNodeValue()));
break;
}
case Node.DOCUMENT_NODE:
case Node.DOCUMENT_FRAGMENT_NODE:
case Node.ELEMENT_NODE: {
Node child = n.getFirstChild();
while (child != null) {
replaceProperties(child);
child = child.getNextSibling();
}
break;
}
default: {
// ignore all other node types
}
}
}
Regards, Upayavira
Upayavira wrote:
Geoff Howard wrote:
No, XPatch doesn't handle properties expansion now. I looked
briefly at how to add support for this and didn't get it worked
out. I don't know Ant internals much at all - maybe someone more
familiar would know better.
I've just asked on ant-dev, and was told:
String org.apache.tools.ant.Project.replaceProperties(String value)
Ok, I tried the other option which looked cleaner - they have a
subclass of Reader which replaces properties on the way in. I
tried it again the other night and found that it throws an NPE when
the task runs. Unfortunately for some reason the line number of
the NPE isn't preserved in the stack trace.
'The other solution?'
So, from looking at the xpatch task, we would have to use this
replaceProperties method on each attribute and text value of each
node in the patch file.
Hmm, I'll look at that solution. I was thinking of slurping the
whole patch file into a string, running replaceProperties on it,
and creating an InputStream from the string to pass to
builder.parse().
That's what Jan Materne on ant-dev suggested too. He's also just
recommended org.apache.tools.ant.util.DOMElementWriter, which might
help.
We could add a 'replace-properties' top level element, which says
whether this should be done.
I haven't followed the specific context here but would love to
see it added too.
I'm a bit busy here, any chance you could look into it, Geoff?
It would be really cool, it would mean that you can mount your
site without having to touch the root sitemap at all.
I can't look into it more now but can pick it up in the next few days.
Great. Lets play a 'who gets there first' game.
Regards, Upayavira
Re: MountTableMatcher
Vadim Gritsenko wrote: Upayavira wrote: After this bit of code turned up, I couldn't resist giving it a go. I now have a XConfToolTask that will replace properties if replace-properties in the top level element is set to true. Is it required, this top level element's attribute? Ant itself does not have it, and always performs replacement (in build.xml), so may be it is not needed? By default our task does not do replacement. I've extended it so that it does, and parameterised it. Replacing parameters by default would slow the build down (but not by much) as all DOM nodes need to be traversed. I have no opinion either way as to whether it should be parameterised or a default. I'll go either way. What do people think? Regards, Upayavira
Re: MountTableMatcher
Upayavira wrote: After this bit of code turned up, I couldn't resist giving it a go. I now have a XConfToolTask that will replace properties if replace-properties in the top level element is set to true. Is it required, this top level element's attribute? Ant itself does not have it, and always performs replacement (in build.xml), so may be it is not needed? Vadim
Re: MountTableMatcher
After this bit of code turned up, I couldn't resist giving it a go.
I now have a XConfToolTask that will replace properties if
replace-properties in the top level element is set to true.
All I've now got to do is work out how to get the task to act on the
root sitemap in all circumstances. So, some digging into the build
process is required.
Regards, Upayavira
Upayavira wrote:
Just had an offer of the following code over at ant-dev, which should
do it nicely (came with an 'untested' disclaimer though).
public void replaceProperties(Node n) throws DOMException {
switch (n.getNodeType()) {
case Node.ATTR_NODE:
case Node.CDATA_SECTION_NODE:
case Node.TEXT_NODE: {
n.setValue(getProject().replaceProperties(n.getNodeValue()));
break;
}
case Node.DOCUMENT_NODE:
case Node.DOCUMENT_FRAGMENT_NODE:
case Node.ELEMENT_NODE: {
Node child = n.getFirstChild();
while (child != null) {
replaceProperties(child);
child = child.getNextSibling();
}
break;
}
default: {
// ignore all other node types
}
}
}
Regards, Upayavira
Upayavira wrote:
Geoff Howard wrote:
No, XPatch doesn't handle properties expansion now. I looked
briefly at how to add support for this and didn't get it worked
out. I don't know Ant internals much at all - maybe someone more
familiar would know better.
I've just asked on ant-dev, and was told:
String org.apache.tools.ant.Project.replaceProperties(String value)
Ok, I tried the other option which looked cleaner - they have a
subclass of Reader which replaces properties on the way in. I tried
it again the other night and found that it throws an NPE when the
task runs. Unfortunately for some reason the line number of the NPE
isn't preserved in the stack trace.
'The other solution?'
So, from looking at the xpatch task, we would have to use this
replaceProperties method on each attribute and text value of each
node in the patch file.
Hmm, I'll look at that solution. I was thinking of slurping the
whole patch file into a string, running replaceProperties on it, and
creating an InputStream from the string to pass to builder.parse().
That's what Jan Materne on ant-dev suggested too. He's also just
recommended org.apache.tools.ant.util.DOMElementWriter, which might
help.
We could add a 'replace-properties' top level element, which says
whether this should be done.
I haven't followed the specific context here but would love to see
it added too.
I'm a bit busy here, any chance you could look into it, Geoff?
It would be really cool, it would mean that you can mount your site
without having to touch the root sitemap at all.
I can't look into it more now but can pick it up in the next few days.
Great. Lets play a 'who gets there first' game.
Regards, Upayavira
Re: MountTableMatcher
Just had an offer of the following code over at ant-dev, which should do
it nicely (came with an 'untested' disclaimer though).
public void replaceProperties(Node n) throws DOMException {
switch (n.getNodeType()) {
case Node.ATTR_NODE:
case Node.CDATA_SECTION_NODE:
case Node.TEXT_NODE: {
n.setValue(getProject().replaceProperties(n.getNodeValue()));
break;
}
case Node.DOCUMENT_NODE:
case Node.DOCUMENT_FRAGMENT_NODE:
case Node.ELEMENT_NODE: {
Node child = n.getFirstChild();
while (child != null) {
replaceProperties(child);
child = child.getNextSibling();
}
break;
}
default: {
// ignore all other node types
}
}
}
Regards, Upayavira
Upayavira wrote:
Geoff Howard wrote:
No, XPatch doesn't handle properties expansion now. I looked
briefly at how to add support for this and didn't get it worked
out. I don't know Ant internals much at all - maybe someone more
familiar would know better.
I've just asked on ant-dev, and was told:
String org.apache.tools.ant.Project.replaceProperties(String value)
Ok, I tried the other option which looked cleaner - they have a
subclass of Reader which replaces properties on the way in. I tried
it again the other night and found that it throws an NPE when the
task runs. Unfortunately for some reason the line number of the NPE
isn't preserved in the stack trace.
'The other solution?'
So, from looking at the xpatch task, we would have to use this
replaceProperties method on each attribute and text value of each
node in the patch file.
Hmm, I'll look at that solution. I was thinking of slurping the
whole patch file into a string, running replaceProperties on it, and
creating an InputStream from the string to pass to builder.parse().
That's what Jan Materne on ant-dev suggested too. He's also just
recommended org.apache.tools.ant.util.DOMElementWriter, which might help.
We could add a 'replace-properties' top level element, which says
whether this should be done.
I haven't followed the specific context here but would love to see
it added too.
I'm a bit busy here, any chance you could look into it, Geoff?
It would be really cool, it would mean that you can mount your site
without having to touch the root sitemap at all.
I can't look into it more now but can pick it up in the next few days.
Great. Lets play a 'who gets there first' game.
Regards, Upayavira
Re: MountTableMatcher
Geoff Howard wrote: No, XPatch doesn't handle properties expansion now. I looked briefly at how to add support for this and didn't get it worked out. I don't know Ant internals much at all - maybe someone more familiar would know better. I've just asked on ant-dev, and was told: String org.apache.tools.ant.Project.replaceProperties(String value) Ok, I tried the other option which looked cleaner - they have a subclass of Reader which replaces properties on the way in. I tried it again the other night and found that it throws an NPE when the task runs. Unfortunately for some reason the line number of the NPE isn't preserved in the stack trace. 'The other solution?' So, from looking at the xpatch task, we would have to use this replaceProperties method on each attribute and text value of each node in the patch file. Hmm, I'll look at that solution. I was thinking of slurping the whole patch file into a string, running replaceProperties on it, and creating an InputStream from the string to pass to builder.parse(). That's what Jan Materne on ant-dev suggested too. He's also just recommended org.apache.tools.ant.util.DOMElementWriter, which might help. We could add a 'replace-properties' top level element, which says whether this should be done. I haven't followed the specific context here but would love to see it added too. I'm a bit busy here, any chance you could look into it, Geoff? It would be really cool, it would mean that you can mount your site without having to touch the root sitemap at all. I can't look into it more now but can pick it up in the next few days. Great. Lets play a 'who gets there first' game. Regards, Upayavira
Re: MountTableMatcher
Upayavira wrote: Geoff Howard 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 build.properties 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... No, XPatch doesn't handle properties expansion now. I looked briefly at how to add support for this and didn't get it worked out. I don't know Ant internals much at all - maybe someone more familiar would know better. I've just asked on ant-dev, and was told: String org.apache.tools.ant.Project.replaceProperties(String value) Ok, I tried the other option which looked cleaner - they have a subclass of Reader which replaces properties on the way in. I tried it again the other night and found that it throws an NPE when the task runs. Unfortunately for some reason the line number of the NPE isn't preserved in the stack trace. So, from looking at the xpatch task, we would have to use this replaceProperties method on each attribute and text value of each node in the patch file. Hmm, I'll look at that solution. I was thinking of slurping the whole patch file into a string, running replaceProperties on it, and creating an InputStream from the string to pass to builder.parse(). We could add a 'replace-properties' top level element, which says whether this should be done. I haven't followed the specific context here but would love to see it added too. I'm a bit busy here, any chance you could look into it, Geoff? It would be really cool, it would mean that you can mount your site without having to touch the root sitemap at all. I can't look into it more now but can pick it up in the next few days. Geoff
Re: MountTableMatcher
Geoff Howard 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 build.properties 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... No, XPatch doesn't handle properties expansion now. I looked briefly at how to add support for this and didn't get it worked out. I don't know Ant internals much at all - maybe someone more familiar would know better. I've just asked on ant-dev, and was told: String org.apache.tools.ant.Project.replaceProperties(String value) So, from looking at the xpatch task, we would have to use this replaceProperties method on each attribute and text value of each node in the patch file. We could add a 'replace-properties' top level element, which says whether this should be done. I haven't followed the specific context here but would love to see it added too. I'm a bit busy here, any chance you could look into it, Geoff? It would be really cool, it would mean that you can mount your site without having to touch the root sitemap at all. Regards, Upayavira
Re: MountTableMatcher
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 build.properties 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... No, XPatch doesn't handle properties expansion now. I looked briefly at how to add support for this and didn't get it worked out. I don't know Ant internals much at all - maybe someone more familiar would know better. I haven't followed the specific context here but would love to see it added too. Geoff
Re: MountTableMatcher
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 build.properties 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... Regards, Upayavira
Re: MountTableMatcher
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I wrote a little goodie that hopefully will be very helpful to all of us: the MountTableMatcher. This is a matcher that manages a "mount table", allowing to add subsitemaps to a Cocoon application without modifying the main sitemap.
Nice one! Great, Sylvain!
A little itch I wanted to scratch for a long time, bored I was to always
remount my apps ;-)
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: MountTableMatcher
Sylvain Wallez wrote: > > I wrote a little goodie that hopefully will be very helpful to all of > us: the MountTableMatcher. This is a matcher that manages a "mount > table", allowing to add subsitemaps to a Cocoon application without > modifying the main sitemap. > Nice one! Great, Sylvain! > > 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)? Carsten
