cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Antwort: Re: [Bug] Default-reader depends on JTidy!!!
Date Wed, 23 Apr 2003 10:19:44 GMT
on 4/22/03 9:44 PM volker.schmitt@basf-it-services.com wrote:

> Stefano,
> 
> what happens if you comment out the
> <parser mime-type="text/html" role
> ="org.apache.excalibur.xml.sax.SAXParser/HTML"/>
> section in the xmlizer element in cocoon.xconf? Then there is no indirect
> reference to JTidyHTMLParser anymore.
> 
> <xmlizer>
>       <parser mime-type="text/html" role
> ="org.apache.excalibur.xml.sax.SAXParser/HTML"/>
>       <parser mime-type="text/xml" role
> ="org.apache.excalibur.xml.sax.SAXParser"/>
>       <parser mime-type="text/plain" role
> ="org.apache.excalibur.xml.sax.SAXParser/Text"/>
> </xmlizer>

Uh, wait, I didn't know it was configurable! gah, I never stop showing
my ignorance on how huge this project is :-)

> I have checked the hole SourceCode (Cocoon2.1 HEAD and Excalibur), the only
> Classes which have direct references to JTidy are:
> org.apache.excalibur.xml.sax.JTidyHTMLParser
> org.apache.cocoon.generation.HTMLGenerator
> 
> JTidyHTMLParser is only used if configured in the <xmlizer> above, but what
> is strange, only if  "toSAX" is used.
> 
> What does the StackTrace show?

Ok, let me try... one sec...

All right, I've checked the <xmlizer> properties and I do have

 <parser mime-type"text/html"
role="org.apache.exalibur.xml.sax.SAXParser/HTML"/>

the stacktrace is

12:14:08.197 WARN!! Error for /prova.html
java.lang.NoClassDefFoundError: org/w3c/tidy/Tidy
        at
org.apache.excalibur.xml.sax.JTidyHTMLParser.initialize(JTidyHTMLParser.java:106)
        at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:282)
        at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:323)
        at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:141)
        at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:266)
        at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:294)
        at
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:106)
        at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:519)
        at
org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:157)
        at
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironment.java:529)
        at
org.apache.cocoon.environment.http.HttpEnvironment.toSAX(HttpEnvironment.java:305)
        at
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironment.java:512)
        at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140)
        at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:283)
        at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:489)
        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.Cocoon.process(Cocoon.java:640)
        at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1103)
        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)

If I remove that line from the configuration it works as advertized.

                                      - o -

This means it's not XMLUtils which is buggy but it's the default
cocoon.xconf that is misleading.

Besides, what does it mean to have a *text* XMLizer? how can you be that
general and still be meaningful? what am I missing?

Anyway, what if we remove the <xMLIzer> section from cocoon.xconf
altogether? it's only confusing: cocoon has enough xml-adaptation
features on its own.

Votes?


-- 
Stefano.



Mime
View raw message