You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Antonio Gallardo <ag...@agssa.net> on 2005/11/01 00:30:45 UTC
Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar
causes failures with linkrewriter protocols site: etc.
David Crossley wrote:
>David Crossley wrote:
>
>
>>Antonio Gallardo wrote:
>>
>>
>>>Antonio Gallardo wrote:
>>>
>>>
>>>>Antonio Gallardo (JIRA) wrote:
>>>>
>>>>
>>>>
>>>>>Can somebody update cocoon jars in Forrest, revert the workaround and
>>>>>check if the bug is fixed. ;-)
>>>>>
>>>>>
>>>>>
>>>>Ok. I am going to update cocoon 2.2 in forrest..... :-)
>>>>
>>>>
>>>Can someone take this task? I was unable to follow the instructions in
>>>etc/cocoon_upgrade there is a problem with the XSP block. :-(
>>>
>>>
>>I too had that trouble a few days ago trying to do a Cocoon
>>upgrade. Today i was successful.
>>
>>And you will be pleased to know that i tested your fix
>>for JXPath and everything works. Thankyou so much Antonio.
>>
>>I will commit the upgrade later today or tommorrow.
>>
>>
>
>Uh'oh, looks like we are one step ahead of ourselves.
>
>See the comments at the Commons JXPath issue:
>http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
>
>Also elharo kindly added a note to the Cocoon bug
>warning that we might have the wrong fix:
>http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
>
>
I wonder why he claims we broke the JXPath implementation. I understand
the new method in jxpath is a hack, but.....
Well, I think we are learning and that is good. :-) If this is the case,
we can try the suggested solution:
Given a simple linkmap.xml as:
*<site* href="" xmlns="http://apache.org/cocoon/linkmap/1.0"*>*
*<myIndex* href="index.html"*/>
</site>
Then the xpath expression "/site/index/@href"
cannot be used. It returns null. The reason is below.
<snip from="http://www.xml.com/pub/a/2004/02/25/qanda.html">
*The real difficulty is that XPath syntax needs to satisfy two
irreconcilable requirements: handling elements in a declared but
default (unprefixed) namespace and handling elements in no namespace
at all, which do not have expanded names. In reconciling this dilemma,
the XPath spec says that an unprefixed name /in an XPath
expression/ is assumed to be in an undeclared namespace, even when
the name as it appears /in the instance document/ has (as a
result of a namespace declaration) an expanded name. Thus, |//myIndex| "query" is instructing XPath to
locate an element which does not exist, a
|"myIndex"| element in an undeclared namespace.
</snip>
*
One of the suggested solutions in the document is strip the default namespace form the file. (This was the David solution).
If the above is not posible, then we can also make a simple trick with JXPath:
*context.registerNamespace(foo, "http://apache.org/cocoon/linkmap/1.0 <http://test>");
and then write the xpath using it:
*"/foo:site/foo:index/@href"*
*
Best Regards,
Antonio Gallardo.
*
Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
Posted by David Crossley <cr...@apache.org>.
Antonio Gallardo wrote:
> David Crossley wrote:
> >Antonio Gallardo wrote:
> >>David Crossley wrote:
> >>>
> >>>See the comments at the Commons JXPath issue:
> >>>http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
> >>>
> >>>Also elharo kindly added a note to the Cocoon bug
> >>>warning that we might have the wrong fix:
> >>>http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
> >>>
> >>I wonder why he claims we broke the JXPath implementation. I understand
> >>the new method in jxpath is a hack, but.....
I reckon that elharo thinks that we are not using
JXPath correctly in Cocoon's Linkrewriter. Probably
requires your solution #3 below.
> >>Well, I think we are learning and that is good. :-) If this is the case,
> >>we can try the suggested solution:
> >>
> >>Given a simple linkmap.xml as:
> >>
> >>*<site* href="" xmlns="http://apache.org/cocoon/linkmap/1.0"*>*
> >>*<myIndex* href="index.html"*/>
> >></site>
> >>
> >>Then the xpath expression "/site/index/@href"
> >
> >Presume you mean "/site/myIndex/@href"
> >
> >>cannot be used. It returns null. The reason is below.
> >>
> >><snip from="http://www.xml.com/pub/a/2004/02/25/qanda.html">
> >>*The real difficulty is that XPath syntax needs to satisfy two
> >>irreconcilable requirements: handling elements in a declared but
> >>default (unprefixed) namespace and handling elements in no namespace
> >>at all, which do not have expanded names. In reconciling this dilemma,
> >>the XPath spec says that an unprefixed name /in an XPath
> >>expression/ is assumed to be in an undeclared namespace, even when
> >>the name as it appears /in the instance document/ has (as a
> >>result of a namespace declaration) an expanded name. Thus, |//myIndex|
> >>"query" is instructing XPath to
> >>locate an element which does not exist, a
> >>|"myIndex"| element in an undeclared namespace.
> >></snip>
> >>*
> >>
> >>One of the suggested solutions in the document is strip the default
> >>namespace form the file. (This was the David solution).
> >>
> >>If the above is not posible, then we can also make a simple trick with
> >>JXPath:
> >>
> >>*context.registerNamespace(foo, "http://apache.org/cocoon/linkmap/1.0
> >>
> >>and then write the xpath using it:
> >>
> >>*"/foo:site/foo:index/@href"*
> >>*
> >
> >Yes, that is what i reckon needs to happen in the Linkrewriter
> >or it gets defined as a parameter for configuration of Cocoon's
> >input modules, or something. Sorry, i am not a good enough
> >Cocooner to know where.
> >
> >One trouble is that we need to handle two possible namespaces.
> >This Linkrewriter started life at Forrest then moved to Cocoon.
> >http://apache.org/forrest/linkmap/1.0
> >http://apache.org/cocoon/linkmap/1.0
> >
> >* Starry, starry night at your place is it Antonio * * * :-)
>
> ?? The "stars" where placed by Thunderbird, not by me. I am sorry for
> that. BTW, you are right, today is a starry night here. How do you knew
> that! ;-) lol.
A guess for the sake of the joke. I knew it was night-time for you.
> I have a question, why we need a namespace in the linkmap.xml at all?
Or in site.xml in the Forrest case.
That was asked earlier in this thread. I reckon that the
answer is so that it clearly defines which version of
the linkrewriter is suitable for processing that file.
Later we might need to radically change the behaviour
of the Linkrewriter, so i suppose that we would require
users to upgrade their site.xml files.
Anyway we already have released versions of Forrest and
Cocoon, with people using namespaces on their site.xml etc.
So we must support it.
> If we really need a default namespace in the linkmap.xml, then let's use
> the correct behavior for XPath 1.0 in the linkrewriter. Hence, use
> something like:
>
> /linkmap:site/linkmap:myIndex/@href for the linkmap rewriter.
>
> The 3rd solution is (not too easy?):
>
> 1- Detect a default namespace URI
> 2-Create a "weird" namespace prefix and register it with the default
> namespace URI
> 3-Rewrite the "location xpath expression" using the generated namespace
> prefix.
>
> Sample:
>
> Given the linkmap:
>
> <site href="" xmlns="http://apache.org/cocoon/linkmap/1.0">
> <myIndex href="index.html"/>
> </site>
>
> and given the location xpath expression:
>
> /site/myIndex/@href
>
> 1- Detect the default namespace URI:
> Output:
> http://apache.org/cocoon/linkmap/1.0
>
> 2-Generate a dummy namespace prefix: cgnp.
> Output: context.registerNamespace("dummy",
> "http://apache.org/cocoon/linkmap/1.0");
>
> 3- Rewrite the xpath expression
> Output: /dummy:site/dummy:myIndex/@href
>
> How sounds this solution?
I feel that this is the way to go.
> Best Regards,
>
> Antonio Gallardo.
>
> P.S: Me expecting this time thunderbird does not wrote a lot of stars
> inbetween mail. :-)
Yes. If the rain clouds rolled in, then send them over here please.
-David
Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar
causes failures with linkrewriter protocols site: etc.
Posted by Antonio Gallardo <ag...@agssa.net>.
David Crossley wrote:
>Antonio Gallardo wrote:
>
>
>>David Crossley wrote:
>>
>>
>>>Uh'oh, looks like we are one step ahead of ourselves.
>>>
>>>See the comments at the Commons JXPath issue:
>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
>>>
>>>Also elharo kindly added a note to the Cocoon bug
>>>warning that we might have the wrong fix:
>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
>>>
>>>
>>>
>>I wonder why he claims we broke the JXPath implementation. I understand
>>the new method in jxpath is a hack, but.....
>>
>>Well, I think we are learning and that is good. :-) If this is the case,
>>we can try the suggested solution:
>>
>>Given a simple linkmap.xml as:
>>
>>*<site* href="" xmlns="http://apache.org/cocoon/linkmap/1.0"*>*
>> *<myIndex* href="index.html"*/>
>></site>
>>
>>Then the xpath expression "/site/index/@href"
>>
>>
>
>Presume you mean "/site/myIndex/@href"
>
>
>
>>cannot be used. It returns null. The reason is below.
>>
>><snip from="http://www.xml.com/pub/a/2004/02/25/qanda.html">
>>*The real difficulty is that XPath syntax needs to satisfy two
>>irreconcilable requirements: handling elements in a declared but
>>default (unprefixed) namespace and handling elements in no namespace
>>at all, which do not have expanded names. In reconciling this dilemma,
>>the XPath spec says that an unprefixed name /in an XPath
>>expression/ is assumed to be in an undeclared namespace, even when
>>the name as it appears /in the instance document/ has (as a
>>result of a namespace declaration) an expanded name. Thus, |//myIndex|
>>"query" is instructing XPath to
>>locate an element which does not exist, a
>>|"myIndex"| element in an undeclared namespace.
>></snip>
>>*
>>
>>One of the suggested solutions in the document is strip the default
>>namespace form the file. (This was the David solution).
>>
>>If the above is not posible, then we can also make a simple trick with
>>JXPath:
>>
>>*context.registerNamespace(foo, "http://apache.org/cocoon/linkmap/1.0
>>
>>and then write the xpath using it:
>>
>>*"/foo:site/foo:index/@href"*
>>*
>>
>>
>
>Yes, that is what i reckon needs to happen in the Linkrewriter
>or it gets defined as a parameter for configuration of Cocoon's
>input modules, or something. Sorry, i am not a good enough
>Cocooner to know where.
>
>One trouble is that we need to handle two possible namespaces.
>This Linkrewriter started life at Forrest then moved to Cocoon.
>http://apache.org/forrest/linkmap/1.0
>http://apache.org/cocoon/linkmap/1.0
>
>
Hi,
See below....
>
>
>>Best Regards,
>>
>>Antonio Gallardo.
>>*
>>
>>
>
>* Starry, starry night at your place is it Antonio * * * :-)
>
>
?? The "stars" where placed by Thunderbird, not by me. I am sorry for
that. BTW, you are right, today is a starry night here. How do you knew
that! ;-) lol.
I am sorry for the errors in my last post. I was in a hurry trying to
send the information to the list and I don't reviewed it as usually I do.
The good news is that the commons-jxpath community seems to accept and
want to keep the request "enhancement". See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c26
The bad news is that seems like we are not using xpath 1.0 in the
linkRewriterTransformer.
I wonder is we used XPath 1.0 notation in the LinkRewriter transformer
since day 1? Is XPath 1.0 the desired expression language? I think we
never used XPath 1.0 or maybe we used it in the beginnng when the
linkmap.xml did not contain a default namespace.
I have a question, why we need a namespace in the linkmap.xml at all?
If we really need a default namespace in the linkmap.xml, then let's use
the correct behavior for XPath 1.0 in the linkrewriter. Hence, use
something like:
/linkmap:site/linkmap:myIndex/@href for the linkmap rewriter.
The 3rd solution is (not too easy?):
1- Detect a default namespace URI
2-Create a "weird" namespace prefix and register it with the default namespace URI
3-Rewrite the "location xpath expression" using the generated namespace prefix.
Sample:
Given the linkmap:
<site href="" xmlns="http://apache.org/cocoon/linkmap/1.0">
<myIndex href="index.html"/>
</site>
and given the location xpath expression:
/site/myIndex/@href
1- Detect the default namespace URI:
Output:
http://apache.org/cocoon/linkmap/1.0
2-Generate a dummy namespace prefix: cgnp.
Output: context.registerNamespace("dummy", "http://apache.org/cocoon/linkmap/1.0");
3- Rewrite the xpath expression
Output: /dummy:site/dummy:myIndex/@href
How sounds this solution?
Best Regards,
Antonio Gallardo.
P.S: Me expecting this time thunderbird does not wrote a lot of stars inbetween mail. :-)
Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
Posted by David Crossley <cr...@apache.org>.
Antonio Gallardo wrote:
> David Crossley wrote:
> >
> >Uh'oh, looks like we are one step ahead of ourselves.
> >
> >See the comments at the Commons JXPath issue:
> >http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
> >
> >Also elharo kindly added a note to the Cocoon bug
> >warning that we might have the wrong fix:
> >http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
> >
> I wonder why he claims we broke the JXPath implementation. I understand
> the new method in jxpath is a hack, but.....
>
> Well, I think we are learning and that is good. :-) If this is the case,
> we can try the suggested solution:
>
> Given a simple linkmap.xml as:
>
> *<site* href="" xmlns="http://apache.org/cocoon/linkmap/1.0"*>*
> *<myIndex* href="index.html"*/>
> </site>
>
> Then the xpath expression "/site/index/@href"
Presume you mean "/site/myIndex/@href"
> cannot be used. It returns null. The reason is below.
>
> <snip from="http://www.xml.com/pub/a/2004/02/25/qanda.html">
> *The real difficulty is that XPath syntax needs to satisfy two
> irreconcilable requirements: handling elements in a declared but
> default (unprefixed) namespace and handling elements in no namespace
> at all, which do not have expanded names. In reconciling this dilemma,
> the XPath spec says that an unprefixed name /in an XPath
> expression/ is assumed to be in an undeclared namespace, even when
> the name as it appears /in the instance document/ has (as a
> result of a namespace declaration) an expanded name. Thus, |//myIndex|
> "query" is instructing XPath to
> locate an element which does not exist, a
> |"myIndex"| element in an undeclared namespace.
> </snip>
> *
>
> One of the suggested solutions in the document is strip the default
> namespace form the file. (This was the David solution).
>
> If the above is not posible, then we can also make a simple trick with
> JXPath:
>
> *context.registerNamespace(foo, "http://apache.org/cocoon/linkmap/1.0
>
> and then write the xpath using it:
>
> *"/foo:site/foo:index/@href"*
> *
Yes, that is what i reckon needs to happen in the Linkrewriter
or it gets defined as a parameter for configuration of Cocoon's
input modules, or something. Sorry, i am not a good enough
Cocooner to know where.
One trouble is that we need to handle two possible namespaces.
This Linkrewriter started life at Forrest then moved to Cocoon.
http://apache.org/forrest/linkmap/1.0
http://apache.org/cocoon/linkmap/1.0
> Best Regards,
>
> Antonio Gallardo.
> *
* Starry, starry night at your place is it Antonio * * * :-)
-David