Would it hurt anything to make this
change in the MountTableMatcher?
From:
// Append a '/' at the end of the prefix
// this avoids flat uri matching which would cause
// exceptions in the sub sitemap!
if (!prefix.endsWith("/")) {
prefix = pre
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
--- Additional Comments From [EMAIL PROTECTED] 2004-10-11 13:11 ---
Thank you very much, Sylvain! Everything now works as it should.
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
--- Additional Comments From [EMAIL PROTECTED] 2004-10-11 12:08 ---
Created an attachment (id=13024)
This includes the sitemaps etc. to show the bug. You will need to change some of the
paths to run it.
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
[EMAIL PROTECTED] changed:
What|Removed |Added
Priority|Other
gzilla/show_bug.cgi?id=31637
MountTableMatcher does not work with generated mount-table
Summary: MountTableMatcher does not work with generated mount-
table
Product: Cocoon 2
Version: 2.1.5
Platform: PC
OS/Version: Wind
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
>
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-th
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:
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 p
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
propertie
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 replac
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,
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
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 diff
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
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
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 Upay
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.
>
> Tha
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 th
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
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
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
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
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
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
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
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
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
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 in
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&#x
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 MountTableMa
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 i
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-tabl
eature 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
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
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-ta
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
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 doe
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 alwa
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,
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.TE
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.a
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
th
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 b
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-tab
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
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.
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.
&g
I all,
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.
This is especially useful for two purpo
51 matches
Mail list logo
