forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
Date Mon, 31 Oct 2005 23:30:45 GMT
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.
*


Mime
View raw message