You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2003/06/04 23:07:30 UTC
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Though we will get again "endorsed lib problem" questions on the users
list, I updated the XML lib jars to their latest releases as in Cocoon
2.1. I hope nobody has something against this. At least we have a good
explanation and solution for these issues now
(http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
added to this wiki page.
But there is another reason for this mail: Now with the current XSLTC we
can switch to it as default processor in 2.0 too, can't we?
And what about the using the treeprocessor as default in Cocoon 2.0? If
it's on the same status as in 2.1, it seems to be stable enough - even
for non-development/milestone releases.
Joerg
joerg@apache.org wrote:
> joerg 2003/06/04 13:50:51
>
> Modified: lib jars.xml
> lib/core xml-apis.jar
> Added: lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
> Removed: lib/core xalan-2.3.1.jar xercesImpl-2.0.0.jar
> Log:
> updating to latest Xalan 2.5.1 and Xerces 2.4.0 releases
Re: ...Bug 20494: Willing to help, but...
Posted by Geoff Howard <co...@leverageweb.com>.
Others have reported that the newer version of xalan is more "strict" with
its expressions and that stylesheets started throwing errors after
upgrade. For them, the solution was to fix the stylesheet and then things
worked well. Check out the users archives over the last few days/week.
As to the excalibur sources, you should be able to do a checkout from
excalibur cvs by date. Check out the tree as it existed on May 20 2003 and
you should have what was used to build that jar, no? I find this a pain
too, but it comes with the territory (external dependencies on unreleased
versions).
Geoff
At 02:25 AM 6/5/2003, you wrote:
>Hmm. I just posted bug 20494 which seemed to appear just after doing an
>update which changed the xalan jar file to version 2.5.1. I also attached
>to this bug a small example that reproduces the problem in the standalone
>jetty + webapp produced by the build.
>
>I'd really like to help look into this, but I just can't seem to obtain
>the source for the excalibur xmlutil package where the errors seem to be
>happening. No other messages are being logged to any of the logfiles in
>WEB-INF/log (Stacktrace appended below if you're curious).
>
>The avalon-excalibur/xmlutil code from CVS HEAD seems to contain
>differences and will not compile against avalon-framework and logkit jars
>from the current cocoon-2.1 CVS HEAD.
>
>How do other developers deal with tracking down problems in these JARs? Is
>there some place I can obtain the source used to build the
>excalibur-xmlutil-20030520.jar file that is in cocoon-2.1 CVS HEAD currently?
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Vadim Gritsenko <va...@verizon.net>.
Joerg Heinicke wrote:
> Though we will get again "endorsed lib problem" questions on the users
> list, I updated the XML lib jars to their latest releases as in Cocoon
> 2.1. I hope nobody has something against this. At least we have a good
> explanation and solution for these issues now
> (http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
> ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
> added to this wiki page.
>
> But there is another reason for this mail: Now with the current XSLTC
> we can switch to it as default processor in 2.0 too, can't we?
>
> And what about the using the treeprocessor as default in Cocoon 2.0?
> If it's on the same status as in 2.1, it seems to be stable enough -
> even for non-development/milestone releases.
There is small issue with the treeprocessor -- nested action sets (see
bugzilla). And Cocoon 2.0 ships with the samples containing those action
sets. It would be pretty upsetting to break those samples.
Once this issue is resolved, +1 from me to use treeprocessor.
Vadim
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Joerg Heinicke wrote:
>>> Isn't it already the default ? The TreeProcessor has now been around
>>> for more than a year...
>>
>>
>> Yep. I checked and the TreeProcessor _is_ the default engine.
>
>
> searched for "tree" in 2.0 cocoon.xconf and didn't find it. after a
> closer look I found it.
The TreeProcessor is the default class for the "sitemap" role. This is
why the class name doesn't appear explicitely in cocoon.xconf
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Joerg Heinicke <jo...@gmx.de>.
>> Isn't it already the default ? The TreeProcessor has now been around
>> for more than a year...
>
> Yep. I checked and the TreeProcessor _is_ the default engine.
searched for "tree" in 2.0 cocoon.xconf and didn't find it. after a
closer look I found it.
Joerg
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> Joerg Heinicke wrote:
>
>> Though we will get again "endorsed lib problem" questions on the
>> users list, I updated the XML lib jars to their latest releases as in
>> Cocoon 2.1. I hope nobody has something against this. At least we
>> have a good explanation and solution for these issues now
>> (http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
>> ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
>> added to this wiki page.
>
> Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
> I'll commit the changes in the 2.0 CVS also, so that we can point
> users to this page.
Done. I also added an optional "servlet-class" parameter, so that the
ParanoidCocoonServlet can be used to sandbox _any_ servlet.
>> But there is another reason for this mail: Now with the current XSLTC
>> we can switch to it as default processor in 2.0 too, can't we?
>>
>> And what about the using the treeprocessor as default in Cocoon 2.0?
>> If it's on the same status as in 2.1, it seems to be stable enough -
>> even for non-development/milestone releases.
>
> Isn't it already the default ? The TreeProcessor has now been around
> for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez wrote:
> Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
> I'll commit the changes in the 2.0 CVS also, so that we can point users
> to this page.
Nice to hear ...
>> But there is another reason for this mail: Now with the current XSLTC
>> we can switch to it as default processor in 2.0 too, can't we?
>>
>> And what about the using the treeprocessor as default in Cocoon 2.0?
>> If it's on the same status as in 2.1, it seems to be stable enough -
>> even for non-development/milestone releases.
>
> Isn't it already the default ? The TreeProcessor has now been around for
> more than a year...
I searched for the configuration in cocoon.xconf and I didn't find it. I
expected to find something similar as in 2.1?
Joerg
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Joerg Heinicke wrote:
> Though we will get again "endorsed lib problem" questions on the users
> list, I updated the XML lib jars to their latest releases as in Cocoon
> 2.1. I hope nobody has something against this. At least we have a good
> explanation and solution for these issues now
> (http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
> ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
> added to this wiki page.
Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
I'll commit the changes in the 2.0 CVS also, so that we can point users
to this page.
> But there is another reason for this mail: Now with the current XSLTC
> we can switch to it as default processor in 2.0 too, can't we?
>
> And what about the using the treeprocessor as default in Cocoon 2.0?
> If it's on the same status as in 2.1, it seems to be stable enough -
> even for non-development/milestone releases.
Isn't it already the default ? The TreeProcessor has now been around for
more than a year...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: ...Bug 20494: Willing to help, but...
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-06-05 at 08:25, Sam Coward wrote:
[...]
>
> Am I even looking at the right place to try and find the problem? Or is
> this error message the by-product of some other hidden exception that
> has been lost?
>
There's indeed a hidden exception: if xsltc fails to compile the
stylesheet, you'll never now why (when using the TemplatesHandler like
we do). If you apply the following patch against xalan you should see
the original exception:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20114
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
...Bug 20494: Willing to help, but...
Posted by Sam Coward <sa...@golden-orb.com>.
Hmm. I just posted bug 20494 which seemed to appear just after doing an
update which changed the xalan jar file to version 2.5.1. I also
attached to this bug a small example that reproduces the problem in the
standalone jetty + webapp produced by the build.
I'd really like to help look into this, but I just can't seem to obtain
the source for the excalibur xmlutil package where the errors seem to be
happening. No other messages are being logged to any of the logfiles in
WEB-INF/log (Stacktrace appended below if you're curious).
The avalon-excalibur/xmlutil code from CVS HEAD seems to contain
differences and will not compile against avalon-framework and logkit
jars from the current cocoon-2.1 CVS HEAD.
How do other developers deal with tracking down problems in these JARs?
Is there some place I can obtain the source used to build the
excalibur-xmlutil-20030520.jar file that is in cocoon-2.1 CVS HEAD
currently?
Am I even looking at the right place to try and find the problem? Or is
this error message the by-product of some other hidden exception that
has been lost?
regards,
Sam
exception follows:
---snip---
Original Exception: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler
at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:380)
at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:302)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:391)
at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:672)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:505)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:467)
at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:133)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:626)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1083)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
Caused by: org.apache.excalibur.xml.xslt.XSLTProcessorException: Unable to create templates for stylesheet: file:/usr/src/cocoon-2.1/build/webapp/test/simple-transform.xml
at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:320)
... 39 more
Original Exception: org.apache.excalibur.xml.xslt.XSLTProcessorException: Unable to create templates for stylesheet: file:/usr/src/cocoon-2.1/build/webapp/test/simple-transform.xml
at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:320)
at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:302)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:391)
at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:672)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:505)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:467)
at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:133)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:626)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1083)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Steven Noels <st...@outerthought.org>.
On 6/06/2003 20:50 Joerg Heinicke wrote:
> Carsten Ziegeler wrote:
>
>>> But there is another reason for this mail: Now with the current XSLTC
>>> we can switch to it as default processor in 2.0 too, can't we?
>>
>>
>> I'm currently -1 on this because imho xsltc has not proven to be 100%
>> working and I think we should at least in 2.0.x have a fully working
>> xslt processor as default.
>
>
> Knowing the problems many users have was the reason for my question. I
> will at least add XSLTC to cocoon.xconf and sitemap to make it easily
> usable.
Seems OK to me. Not only does XSLTC _still_ have some issues, the Xalan
folks are not very active in applying patches, too.
But still, people who want to make use of XSLTC will be happy to see it
being made easily usable.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Joerg Heinicke <jo...@gmx.de>.
Carsten Ziegeler wrote:
>>But there is another reason for this mail: Now with the current XSLTC we
>>can switch to it as default processor in 2.0 too, can't we?
>
> I'm currently -1 on this because imho xsltc has not proven to be 100%
> working and I think we should at least in 2.0.x have a fully working
> xslt processor as default.
Knowing the problems many users have was the reason for my question. I
will at least add XSLTC to cocoon.xconf and sitemap to make it easily
usable.
Joerg
RE: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar xml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Joerg Heinicke wrote:
>
> But there is another reason for this mail: Now with the current XSLTC we
> can switch to it as default processor in 2.0 too, can't we?
>
I'm currently -1 on this because imho xsltc has not proven to be 100%
working and I think we should at least in 2.0.x have a fully working
xslt processor as default.
Carsten