[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12356462 ] 

David Crossley commented on FOR-675:


Well it works. However see today's forrest-dev email discussion. The solution 
is not yet correct.


> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Critical
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

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:
> >>
> >>*http://apache.org/cocoon/linkmap/1.0"*>*
> >>*
> >>
> >>
> >>Then the xpath expression "/site/index/@href"
> >
> >Presume you mean "/site/myIndex/@href"
> >
> >>cannot be used. It returns null. The reason is below.
> >>
> >>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.
> >>
> >>*
> >>
> >>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:
> 
> http://apache.org/cocoon/linkmap/1.0";>
> 
> 
> 
> 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.

[Antonio Gallardo]

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:

*http://apache.org/cocoon/linkmap/1.0"*>*
*


Then the xpath expression "/site/index/@href"
   



Presume you mean "/site/myIndex/@href"

 


cannot be used. It returns null. The reason is below.

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.

*

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:

http://apache.org/cocoon/linkmap/1.0";>



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.

[David Crossley]

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:
> 
> *http://apache.org/cocoon/linkmap/1.0"*>*
>  *
> 
> 
> Then the xpath expression "/site/index/@href"

Presume you mean "/site/myIndex/@href"

> cannot be used. It returns null. The reason is below.
> 
> 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.
> 
> *
> 
> 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

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

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:

*http://apache.org/cocoon/linkmap/1.0"*>*
 *


Then the xpath expression "/site/index/@href"

cannot be used. It returns null. The reason is below.


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.

*

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"*
*

Best Regards,

Antonio Gallardo.
*

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

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.
 


Great!


I will commit the upgrade later today or tommorrow.
 


Thanks David, for update forrest. :-)

Best Regards,

Antonio Gallardo.

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

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

-David

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Thorsten Scherler]

El lun, 31-10-2005 a las 16:27 +1100, David Crossley escribió:
> 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.

:)

Thx a million! 

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

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.

-David

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

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. :-(




Best Regards,

Antonio Gallardo.

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

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. :-)

Best Regards,

Antonio Gallardo.

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12356306 ] 

Antonio Gallardo commented on FOR-675:
--

The problem is fixed in Cocoon 2.2 SVN. See:

http://issues.apache.org/jira/browse/COCOON-1616?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel

Can somebody update cocoon jars in Forrest, revert the workaround and check if 
the bug is fixed. ;-)

Thanks in advance.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Critical
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

David Crossley wrote:


Antonio Gallardo wrote:
 


Hi forresters!

Seems like my "crazy" idea got accepted. ;-)

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c10

Do you think this is going to help us to fix this error? :-)
   



I don't profess to understand the issues involved.

The final solution sounds like it will enable us to
make a useful workaround ... an API to define non-standard
things, e.g. context.setDefaultNamespaceIgnored(true)
 

It is non-standard for XPath 1.0, but it is standard for XPath 2.0. 
Hence, we need a XPath 2.0 feature in a XPath 1.0 implementation. ;-)


BTW, Maybe we may suggest a new name for the method.  :-)

Best Regards,

Antonio Gallardo.



In XPath 2.0 this is like:



Interesting. That is similar to the workaround that i am
currently trying to do, except from the Forrest end of things
before Cocoon input modules and JXPath read our site.xml file.

Thanks for your contributions.
 


Thanks to you.


-David
 

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12356040 ] 

David Crossley commented on FOR-675:


The other workround has now been implemented at Forrest, as it might take some 
time to get through Commons JXPath and then Cocoon. This workaround uses a 
sitemap pipeline to strip all namespaces from the site.xml before it is 
injested by Cocoon input modules. Sorry for the delay, it took me a long time 
to realise that namespaces are not actually removed until the xml is 
serialised. See svn revision 328770

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12356038 ] 

David Crossley commented on FOR-675:


There are now useful suggestions to provide workarounds for namespace issues at 
the Commons JXPath:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
"[jxpath] Default Namespace not handled correctly"

Cocoon input modules could possibly make use of that, or maybe find a better 
solution.

Cocoon issues have moved from Bugzilla to the ASF Jira ...
http://issues.apache.org/jira/browse/COCOON-1616
"source that declares namespace fails JXPath/Linkrewriter/Input Modules"

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Thorsten Scherler]

Wow, many thanks!

That is great stuff, Antonio. I have to admit after reading a couple of
times I still do not fully understand.

BTW sorry for not being a bigger help on that, but is PITA to debug the
code without internet connection @home. I owe you big time. ;-)

salu2

El mié, 26-10-2005 a las 15:16 +1000, David Crossley escribió:
> Antonio Gallardo wrote:
> > Hi forresters!
> > 
> > Seems like my "crazy" idea got accepted. ;-)
> > 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c10
> > 
> > Do you think this is going to help us to fix this error? :-)
> 
> I don't profess to understand the issues involved.
> 
> The final solution sounds like it will enable us to
> make a useful workaround ... an API to define non-standard
> things, e.g. context.setDefaultNamespaceIgnored(true)
> 
> Interesting. That is similar to the workaround that i am
> currently trying to do, except from the Forrest end of things
> before Cocoon input modules and JXPath read our site.xml file.
> 
> Thanks for your contributions.
> 
> -David
> 
> > >Antonio Gallardo commented on FOR-675:
> > >--
> > >
> > >Interesting reading. Shows why the problems happens and posible solutions: 
> > >http://www.xml.com/pub/a/2004/02/25/qanda.html
> > >
> > >>upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> > >>protocols site: etc.
> > >>--
> > >>
> > >>Key: FOR-675
> > >>URL: http://issues.apache.org/jira/browse/FOR-675
> > >>Project: Forrest
> > >>   Type: Bug
> > >> Components: Core operations
> > >>   Versions: 0.7, 0.8-dev
> > >>   Reporter: David Crossley
> > >>   Priority: Blocker
> > >>Fix For: 0.8-dev
> > >
> > >>upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar 
> > >>causes failures with linkrewriter protocols site: etc. This happens in 
> > >>both modes: 'forret run' and 'forrest'.
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

Antonio Gallardo wrote:
> Hi forresters!
> 
> Seems like my "crazy" idea got accepted. ;-)
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c10
> 
> Do you think this is going to help us to fix this error? :-)

I don't profess to understand the issues involved.

The final solution sounds like it will enable us to
make a useful workaround ... an API to define non-standard
things, e.g. context.setDefaultNamespaceIgnored(true)

Interesting. That is similar to the workaround that i am
currently trying to do, except from the Forrest end of things
before Cocoon input modules and JXPath read our site.xml file.

Thanks for your contributions.

-David

> >Antonio Gallardo commented on FOR-675:
> >--
> >
> >Interesting reading. Shows why the problems happens and posible solutions: 
> >http://www.xml.com/pub/a/2004/02/25/qanda.html
> >
> >>upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> >>protocols site: etc.
> >>--
> >>
> >>Key: FOR-675
> >>URL: http://issues.apache.org/jira/browse/FOR-675
> >>Project: Forrest
> >>   Type: Bug
> >> Components: Core operations
> >>   Versions: 0.7, 0.8-dev
> >>   Reporter: David Crossley
> >>   Priority: Blocker
> >>Fix For: 0.8-dev
> >
> >>upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar 
> >>causes failures with linkrewriter protocols site: etc. This happens in 
> >>both modes: 'forret run' and 'forrest'.

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

Hi forresters!

Seems like my "crazy" idea got accepted. ;-)

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c10

Do you think this is going to help us to fix this error? :-)

Best Regards,

Antonio Gallardo.

Antonio Gallardo (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12349911 ] 


Antonio Gallardo commented on FOR-675:
--

Interesting reading. Shows why the problems happens and posible solutions: 
http://www.xml.com/pub/a/2004/02/25/qanda.html

 


upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols 
site: etc.
--

Key: FOR-675
URL: http://issues.apache.org/jira/browse/FOR-675
Project: Forrest
   Type: Bug
 Components: Core operations
   Versions: 0.7, 0.8-dev
   Reporter: David Crossley
   Priority: Blocker
Fix For: 0.8-dev
   



 


upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
failures with linkrewriter protocols site: etc. This happens in both modes: 
'forret run' and 'forrest'.
   



 

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12349911 ] 

Antonio Gallardo commented on FOR-675:
--

Interesting reading. Shows why the problems happens and posible solutions: 
http://www.xml.com/pub/a/2004/02/25/qanda.html

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

David Crossley wrote:


Antonio Gallardo wrote:
 


David Crossley wrote:
   


Thanks, i have been spending a huge amount of time on it.
I have been deep in Cocoon input modules and JXPath,
but i am not getting far. It needs someone with better
Java/XML/Namespace/Cocoon foo.
 

Yes, thanks David. But why you think we need deep cocon understanding to 
fix this bug? I am just asking. :-)
   



Because the commons-jxpath issue report seems to
say that it is in the way that we (Cocoon) are
using the library. They are adamant not to change it.
 



I was working on that since my last mail, please review if this make sense:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c7

 

I believe, the problem is inside the commons-jxpath itself, as I posted 
in my latest report in jira. In short, 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360


To me the next step is forget cocoon for a while, create a simple 
testcase for the jxpath library check the error is there and fix it. 
Once the jxpath is fixed, import the patched lib to forrest. I bet it is 
going to work. ;-)
   



It probably would. However the Commons JXPath people
have said that they won't fix it. Perhaps you can
convince them. Good luck.
 

lol. Please cross your fingers too, if my last bugzilla comment make 
sense to them, then I hope we will have soon a patch. ;-)



So that is why i was burrowing into Cocoon's
JXPath usage.
 

No matter how hard you will try. I think there is no way in cocoon to 
fix that. This is my 4th iteration trying to fix this error in a year. 
The first one was right after Ghent 2004. Do you remember?


I think jxpath community missundertood the xpath specification. Well, 
maybe I am fully wrong. But my common sense tell me that is really hard 
to believe that all the xalan team (before in IBM and now in Apache) + 
Michael Kay, the saxon expert, all this people were unable to understand 
correctly the xpath specification. At least in the Michael Kay case, he 
was one of the people who wrote it! Hence it is imposible he then did a 
mistake interpretaing the same specification when he wrote in Saxon. ;-)


Best Regards,

Antonio Gallardo.

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332747 ] 

David Crossley commented on FOR-675:


Discussion and effort on the forrest-dev mailing list. See the various Re: 675 
threads.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

Antonio Gallardo wrote:
> David Crossley wrote:
> >
> >Thanks, i have been spending a huge amount of time on it.
> >I have been deep in Cocoon input modules and JXPath,
> >but i am not getting far. It needs someone with better
> >Java/XML/Namespace/Cocoon foo.
>
> Yes, thanks David. But why you think we need deep cocon understanding to 
> fix this bug? I am just asking. :-)

Because the commons-jxpath issue report seems to
say that it is in the way that we (Cocoon) are
using the library. They are adamant not to change it.

> I believe, the problem is inside the commons-jxpath itself, as I posted 
> in my latest report in jira. In short, 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32360
> 
> To me the next step is forget cocoon for a while, create a simple 
> testcase for the jxpath library check the error is there and fix it. 
> Once the jxpath is fixed, import the patched lib to forrest. I bet it is 
> going to work. ;-)

It probably would. However the Commons JXPath people
have said that they won't fix it. Perhaps you can
convince them. Good luck.

So that is why i was burrowing into Cocoon's
JXPath usage.

-David

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

Antonio Gallardo wrote:


David Crossley wrote:


Ross Gardler wrote:
 


David Crossley (JIRA) wrote:
  

  [   
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323 
]

David Crossley commented on FOR-675:


There is a simple way to avoid these issues.

Remove the xmlns attribute from every site.xml and make the 
following change. The linkrewriter can then be used with the 
updated JXPath library.



Is this is a robust workaround? I'm not intimate enough with the 
navigation generation to be able to predict the potential side 
effects of this.
  



I don't know either, but everything seems to be working.

Haven't tried the views dispatcher yet.

It is a drastic change, but this issue is too.

One thing that it would affect is the future ability to have
a new version of the namespace. I reckon that we should
sacrifice that to get past this bug.

 

(by the way, thank you David for keeping at this issue, I've been 
hiding from it ;-)
  



Thanks, i have been spending a huge amount of time on it.
I have been deep in Cocoon input modules and JXPath,
but i am not getting far. It needs someone with better
Java/XML/Namespace/Cocoon foo.
 

Yes, thanks David. But why you think we need deep cocon understanding 
to fix this bug? I am just asking. :-)


I believe, the problem is inside the commons-jxpath itself, as I 
posted in my latest report in jira. In short, 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360


To me the next step is forget cocoon for a while, create a simple 
testcase for the jxpath library check the error is there and fix it. 
Once the jxpath is fixed, import the patched lib to forrest. I bet it 
is going to work. ;-)


Unfortunately, for the lack of time recently, I was unable to follow 
do that. :-(


I just let know commons-jxpath community the problem we have:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c5

I hope they help us! :-)

Best Regards,

Antonio Gallardo.

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo]

David Crossley wrote:


Ross Gardler wrote:
 


David Crossley (JIRA) wrote:
   

  [ 
  http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323 ] 


David Crossley commented on FOR-675:


There is a simple way to avoid these issues.

Remove the xmlns attribute from every site.xml and make the following 
change. The linkrewriter can then be used with the updated JXPath library.
 

Is this is a robust workaround? I'm not intimate enough with the 
navigation generation to be able to predict the potential side effects 
of this.
   



I don't know either, but everything seems to be working.

Haven't tried the views dispatcher yet.

It is a drastic change, but this issue is too.

One thing that it would affect is the future ability to have
a new version of the namespace. I reckon that we should
sacrifice that to get past this bug.

 

(by the way, thank you David for keeping at this issue, I've been hiding 
from it ;-)
   



Thanks, i have been spending a huge amount of time on it.
I have been deep in Cocoon input modules and JXPath,
but i am not getting far. It needs someone with better
Java/XML/Namespace/Cocoon foo.
 

Yes, thanks David. But why you think we need deep cocon understanding to 
fix this bug? I am just asking. :-)


I believe, the problem is inside the commons-jxpath itself, as I posted 
in my latest report in jira. In short, 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360


To me the next step is forget cocoon for a while, create a simple 
testcase for the jxpath library check the error is there and fix it. 
Once the jxpath is fixed, import the patched lib to forrest. I bet it is 
going to work. ;-)


Unfortunately, for the lack of time recently, I was unable to follow do 
that. :-(


Best Regards,

Antonio Gallardo.

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Ross Gardler]

Thorsten Scherler wrote:

El mar, 18-10-2005 a las 19:19 +1000, David Crossley escribió:



...


David Crossley (JIRA) wrote:


...


And it is
preventing me working on real issues.



Yeah, we should propose to drop the ns for the time this bug is being
fixed and go on with our work.

+1

Anyway, as soon as v2 is totally based on the lm, I will give it another
go. (hopefully then I have internet @home again)


This issue is not affecting my current work directly, but if it is 
holding other devs up then I'm OK with this (it will affect me soon anyway).


Ross

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Thorsten Scherler]

El mar, 18-10-2005 a las 19:19 +1000, David Crossley escribió:
> Ross Gardler wrote:
> > David Crossley (JIRA) wrote:
> > >[ 
> > >
> > > http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323
> > >  ] 
> > >
> > >David Crossley commented on FOR-675:
> > >
> > >
> > >There is a simple way to avoid these issues.
> > >
> > >Remove the xmlns attribute from every site.xml and make the following 
> > >change. The linkrewriter can then be used with the updated JXPath library.
> > 
> > Is this is a robust workaround? I'm not intimate enough with the 
> > navigation generation to be able to predict the potential side effects 
> > of this.
> 
> I don't know either, but everything seems to be working.
> 
> Haven't tried the views dispatcher yet.

I will do that.

> It is a drastic change, but this issue is too.

jeje, just wait till I have the first version ready. ;-) While doing the
lm rewrite of the dispatcher I found many parts of the processing that
we should change that we can use contracts in e.g. xml processing of the
data model.

> One thing that it would affect is the future ability to have
> a new version of the namespace. I reckon that we should
> sacrifice that to get past this bug.

+1 

We can always bring it back, if we (or somebody else) can fix the bug.

> > (by the way, thank you David for keeping at this issue, I've been hiding 
> > from it ;-)
> 
> Thanks, i have been spending a huge amount of time on it.
> I have been deep in Cocoon input modules and JXPath,
> but i am not getting far. It needs someone with better
> Java/XML/Namespace/Cocoon foo.

Yeah thx very much, David. I tried for a while but there many components
involved. It is pretty heavy to understand each component before being
able to fix this bug. Again thx David that you are doing this, it is
most valuable for forrest.

> 
> I see this as a crucial issue. We now have various
> whiteboard plugins with fixme comments about JXPath
> and disabled linkrewriter sitemaps and duplicated
> documentation trying to explain all that. 

It is even worse because if we e.g. want a cform plugin then this will
have another of this fixme notes. :/ trying to say that many blocks of
cocoon depending on JX 1.2.

> And it is
> preventing me working on real issues.

Yeah, we should propose to drop the ns for the time this bug is being
fixed and go on with our work.

+1

Anyway, as soon as v2 is totally based on the lm, I will give it another
go. (hopefully then I have internet @home again)

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley]

Ross Gardler wrote:
> David Crossley (JIRA) wrote:
> >[ 
> >
> > http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323 
> > ] 
> >
> >David Crossley commented on FOR-675:
> >
> >
> >There is a simple way to avoid these issues.
> >
> >Remove the xmlns attribute from every site.xml and make the following 
> >change. The linkrewriter can then be used with the updated JXPath library.
> 
> Is this is a robust workaround? I'm not intimate enough with the 
> navigation generation to be able to predict the potential side effects 
> of this.

I don't know either, but everything seems to be working.

Haven't tried the views dispatcher yet.

It is a drastic change, but this issue is too.

One thing that it would affect is the future ability to have
a new version of the namespace. I reckon that we should
sacrifice that to get past this bug.

> (by the way, thank you David for keeping at this issue, I've been hiding 
> from it ;-)

Thanks, i have been spending a huge amount of time on it.
I have been deep in Cocoon input modules and JXPath,
but i am not getting far. It needs someone with better
Java/XML/Namespace/Cocoon foo.

I see this as a crucial issue. We now have various
whiteboard plugins with fixme comments about JXPath
and disabled linkrewriter sitemaps and duplicated
documentation trying to explain all that. And it is
preventing me working on real issues.

-David

Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Ross Gardler]

David Crossley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323 ] 


David Crossley commented on FOR-675:


There is a simple way to avoid these issues.

Remove the xmlns attribute from every site.xml and make the following change. 
The linkrewriter can then be used with the updated JXPath library.


Is this is a robust workaround? I'm not intimate enough with the 
navigation generation to be able to predict the potential side effects 
of this.


(by the way, thank you David for keeping at this issue, I've been hiding 
from it ;-)


Ross

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12332323 ] 

David Crossley commented on FOR-675:


There is a simple way to avoid these issues.

Remove the xmlns attribute from every site.xml and make the following change. 
The linkrewriter can then be used with the updated JXPath library.

-
Index: main/webapp/resources/stylesheets/site-to-book.xsl
===
--- main/webapp/resources/stylesheets/site-to-book.xsl  (revision 326016)
+++ main/webapp/resources/stylesheets/site-to-book.xsl  (working copy)
@@ -31,7 +31,7 @@
 
   
 
-  
+  
-

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12331590 ] 

David Crossley commented on FOR-675:


According to that bug, it seems that Cocoon use of JXPath could be improved in 
our input modules.
I spent another day investigating, to no avail.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12330776 ] 

Antonio Gallardo commented on FOR-675:
--

Thanks for the demo in cocoon 2.2. It helps a lot. I found the bug is already 
filled for commons-jxpath:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360

The next step is review the commons-jxpath code.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12330771 ] 

David Crossley commented on FOR-675:


I had already tried adding the "namespace-uri" parameter to the Forrest 
sitemaps (see above) but that had no effect. The value was as declared in the 
site-author/content/xdocs/site.xml (http://apache.org/forrest/linkmap/1.0). I 
tried again today to no avail.

The sample that you enhanced in Cocoon-2.1 was the old "bookdemo". I was using 
the "sitedemo" in Cocoon trunk 2.2 because that is closer to what we have in 
Forrrest. Today i added a demonstration of the problem to Cocoon 2.2

You wonder why JXPath raises the issue. So did i, which is why the Bugzilla 
entry mentions "Input Modules". These are used to inject the site.xml file and 
JXPath is involved with Input Modules.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
"source that declares namespace fails JXPath/Linkrewriter/Input Modules"




> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12330669 ] 

Antonio Gallardo commented on FOR-675:
--

On Cocoon 2.1.8-dev (and I believe on cocoon 2.2.-dev it works too) I was able 
to run a sample including namespaces. See this matcher with 2 
LinkRewriterTransformer calls:


   
   

   
   
 http://www.w3.org/1999/xhtml"/>
   

   
   
 

I am just wondering why this problem is raised by jxpath 1.2. I don't saw in 
the LinkRewriterTransformer jxpath references at all. Can somebody try this on 
forrest? Here is too late right now and I am sleeping. ;-)

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12330444 ] 

David Crossley commented on FOR-675:


This issue has been recorded at Cocoon:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36810
"source that declares namespace fails JXPath/Linkrewriter/Input Modules"

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
> Priority: Blocker
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Thorsten Scherler (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12330414 ] 

Thorsten Scherler commented on FOR-675:
---

The problem I have in debugging the 
org.apache.cocoon.transformation.LinkRewriterTransformer class in eclipse is 
that I got:

"Unable to install breakpoint in ... due to missing line number attributes. 
Modify compiler options to generate line number attributes.
Reason: Absent line number information"

See 
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-7304.html for a similar 
problem. 

I patched cocoons compile-build.xml like:
Index: compile-build.xml
===
--- compile-build.xml   (revisión: 291352)
+++ compile-build.xml   (copia de trabajo)
@@ -24,6 +24,7 @@
   
   
   upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Juan Jose Pablos (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329750 ] 

Juan Jose Pablos commented on FOR-675:
--

Done. Cocoon is build right now with debug=on please re-test this if you can 
and report back.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329749 ] 

David Crossley commented on FOR-675:


I reckon that we need debug on all the time.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Juan Jose Pablos (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329738 ] 

Juan Jose Pablos commented on FOR-675:
--

If we need to enable debug to fix this issue. Please let me know... I can do 
that very easily.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.8-dev, 0.7
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329669 ] 

Antonio Gallardo commented on FOR-675:
--

Yes. On the jxpath release notes there is an important note about namespaces 
[1]. The LinkTransformer source [2] shows that the "namespace-uri" parameter is 
only used at setup and never later! I believe we need to include in the 
LinkRewriterTransformer javadocs this sentence:

"Actually, only links in the default ("") namespace are converted."

I think the next step is setup a sample using LinkRewriterTransformer and 
namespaces in cocoon to see if it works properly. IMHO, is more easy to fix the 
error in cocoon and then just update cocoon jars in forrest.

BTW, I found difficult to trace the error in forrest, the cocoon jars 
distributed in forrest does not have debug info. Will be fine to include debug 
info in ocoon.jars for forrest.

[1] http://jakarta.apache.org/commons/jxpath/release-notes-1.2.html
[2] 
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/linkrewriter/trunk/java/org/apache/cocoon/transformation/LinkRewriterTransformer.java?view=markup


> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329668 ] 

David Crossley commented on FOR-675:


Removing the namespace declaration from our site.xml lets the "site:" etc. 
links get resolved properly. However doing that removes the left-hand menus 
too. Obviously not the solution, but shows that namespace is something to do 
with the problem.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329667 ] 

David Crossley commented on FOR-675:


The linkrewriter transformer can be configured in our sitemap.xmap with a 
"namespace-uri" parameter, but that seems to have no effect.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329666 ] 

David Crossley commented on FOR-675:


The samples in the linkrewriter block at cocoon trunk do not exhibit this 
problem.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329647 ] 

David Crossley commented on FOR-675:


Turn the log level up to DEBUG for the linkrewriter stuff in 
WEB-INF/logkit.xconf shows that the linkrewriter is now returning null for 
these lookups.

> upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter 
> protocols site: etc.
> --
>
>  Key: FOR-675
>  URL: http://issues.apache.org/jira/browse/FOR-675
>  Project: Forrest
> Type: Bug
>   Components: Core operations
> Versions: 0.7, 0.8-dev
> Reporter: David Crossley
>  Fix For: 0.8-dev

>
> upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes 
> failures with linkrewriter protocols site: etc. This happens in both modes: 
> 'forret run' and 'forrest'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira