|
[
Permlink
| « Hide
]
David Crossley added a comment - 18/Sep/05 09:06 AM
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.
The samples in the linkrewriter block at cocoon trunk do not exhibit this problem.
The linkrewriter transformer can be configured in our sitemap.xmap with a "namespace-uri" parameter, but that seems to have no effect.
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.
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 If we need to enable debug to fix this issue. Please let me know... I can do that very easily.
I reckon that we need debug on all the time.
Done. Cocoon is build right now with debug=on please re-test this if you can and report back.
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 @@ <!-- compilation parts used by all targets --> <presetdef name="cocoon.javac"> <javac + debuglevel="lines,vars,source" debug="${compiler.debug}" optimize="${compiler.optimize}" deprecation="${compiler.deprecation}" wich was recommended in the link. Then I copied the linkrewriter block lib to the core and could connect to the class to debug. :) HTH 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" 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:
<map:match pattern="*.html"> <map:generate src="docs/{1}.html"/> <map:transform type="linkrewriter" src="cocoon:/linkmap"/> <!-- +++++ For the pages that have a non empty default namespace ++++++++++++ --> <map:transform type="linkrewriter" src="cocoon:/linkmap"> <map:parameter name="namespace-uri" value="http://www.w3.org/1999/xhtml"/> </map:transform> <map:serialize/> <map:serialize type="xml"/> </map:match> 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. ;-) 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" 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. 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. 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 @@ <xsl:apply-templates/> </xsl:template> - <xsl:template match="f:site"> + <xsl:template match="site"> ------------------------- Discussion and effort on the forrest-dev mailing list. See the various Re: 675 threads.
Interesting reading. Shows why the problems happens and posible solutions: http://www.xml.com/pub/a/2004/02/25/qanda.html
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" 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
Reduced priority from Blocker to Critical, as we at least have a workaround now.
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. Well it works. However see today's forrest-dev email discussion. The solution is not yet correct.
Reducing priotiry and moving to 0.9
We have a workaround in place, but we need to create a more robuist solution. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
