You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2009/05/27 00:24:52 UTC
Re: C3: Xalan runtime error when using include and xslt transformers
back to back in pipeline
Hi Yoann,
sorry, I overlooked your message.
After looking into the IncludeTransformer I'm not sure why you think
that the endDocument() method is called for every included xml chunk.
The transformer uses following code to include XML:
XMLReader xmlReader = XMLReaderFactory.createXMLReader();
EmbeddedSAXPipe embeddedSAXPipe =
new EmbeddedSAXPipe(this.getSAXConsumer());
xmlReader.setContentHandler(embeddedSAXPipe);
xmlReader.setProperty("http://xml.org/sax/properties/lexical-handler",
embeddedSAXPipe);
BufferedInputStream inputStream =
new BufferedInputStream(source.openStream());
xmlReader.parse(new InputSource(inputStream));
The embedded SAX pipe takes care that the startDocument() and
endDocument() methods are never called.
It would be great if you created a (failing) test case that demonstrates
your problem. Thanks!
Reinhard
Yoann Archambault wrote:
> Hi,
>
> Sorry i haven't gotten around to providing an example of my problem, but
> i believe i found the source.
> The include transformer creates endDocument sax events for every
> included xml chunk.
> Maybe it was the same thing that was messing with the xslt transformer,
> but it most certainly is messing with the SSF. In the case of an SSF
> serializer, on endDocument the serializer sends an incomplete document
> down to the SSF consumer generator.
>
> For example the following include file
>
> <?xml version='1.0' encoding='utf-8'?>
> <response xmlns:i="http://apache.org/cocoon/3.0/include">
> <i:include src="blockcontext:/Core/xml/testpart1.xml"/>
> <i:include src="blockcontext:/Core/xml/testpart2.xml"/>
> <i:include src="blockcontext:/Core/xml/testpart3.xml"/>
> </response>
>
> would recieve an endDocument at this point, obviously sending an
> incomplete document:
>
> <response xmlns:i="http://apache.org/cocoon/3.0/include">
> <testpart1>
> <foo>bar</foo>
> </testpart1>
>
>
> and the consumer pipeline (/serializer/params) crashes saying:
>
> [Fatal Error] :15:8: XML document structures must start and end within
> the same entity.
>
> Caused by: java.io.IOException: Can't connect to servlet URL
> servlet:/serializer/params.
> at
> org.apache.cocoon.servlet.ssf.ServletServiceSerializer.endDocument(ServletServiceSerializer.java:56)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:737)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> at
> org.apache.cocoon.sax.component.IncludeTransformer.startElement(IncludeTransformer.java:72)
>
>
>
> Pretty straightforward... no need for a test this time around :p
> Yoann
>
> On Wed, 2009-03-25 at 14:13 +0100, Reinhard Pötz wrote:
>> Yoann,
>>
>> could you provide us with a integration test please because we haven't
>> been able to reproduce your problem. Just add your failing example to
>> the cocoon-samples module, create a patch and add it to the Cocoon 3 Jira.
>>
>> Thanks in advance!
>>
>> Reinhard
>>
>> Yoann Archambault wrote:
>>> Hi again!
>>> I'm afraid i spoke too soon... after i removed the xsl:output the error
>>> changed but its still there.
>>> This time around i dug a bit more and found that xalan's
>>> TransformerImpl.setContentHandler(handler) never gets called.
>>> setContentHandler also sets m_serializationHandler, which is used for
>>> synchronization during the xsl transformation in transformNode():1234
>>>
>>> I dont know which component has the responsability to call this
>>> setContentHandler. At first i thought about cocoon's
>>> XSLTTransformer.setSAXConsumer() but i might be off since i dont have
>>> the big picture in mind...
>>>
>>> At a glance i would say someone expected xalan to do something it can't
>>> do :)
>>>
>>> Here are some stacks:
>>>
>>> Found this when i dug into xalan's try-catches.
>>> This is where m_serializationHandler is used.
>>>
>>> java.lang.NullPointerException
>>> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1234)
>>> at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3383)
>>> at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:389)
>>> at org.apache.cocoon.xml.sax.AbstractSAXPipe.endDocument(AbstractSAXPipe.java:58)
>>> at org.apache.cocoon.sax.AbstractSAXTransformer.endDocument(AbstractSAXTransformer.java:47)
>>> at org.apache.cocoon.sax.AbstractSAXTransformer.endDocument(AbstractSAXTransformer.java:47)
>>> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:737)
>>> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
>>> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
>>> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
>>> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
>>> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:87)
>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:113)
>>>
>>>
>>> Cocoon's side:
>>>
>>> Caused by: org.apache.cocoon.pipeline.ProcessingException: Can't parse
>>> url connection blockcontext:/Core/html/ReferenceNodeEdit.html
>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:117)
>>> at org.apache.cocoon.sax.component.FileGenerator.execute(FileGenerator.java:81)
>>> at org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:147)
>>> at org.apache.cocoon.pipeline.CachingPipeline.execute(CachingPipeline.java:124)
>>> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
>>> Caused by: java.lang.RuntimeException
>>> at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3418)
>>> at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:389)
>>> at org.apache.cocoon.xml.sax.AbstractSAXPipe.endDocument(AbstractSAXPipe.java:58)
>>> at org.apache.cocoon.sax.AbstractSAXTransformer.endDocument(AbstractSAXTransformer.java:47)
>>> at org.apache.cocoon.sax.AbstractSAXTransformer.endDocument(AbstractSAXTransformer.java:47)
>>> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:737)
>>> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
>>> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
>>> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
>>> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
>>> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:87)
>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:113)
>>> ... 82 more
>>>
>>>
>>>
>>> and here the is master pipeline in this context
>>>
>>> <map:match pattern="html/**.html">
>>> <map:match pattern="html/inc/**.html">
>>> <map:generate src="html/{map:1}.html" />
>>> <map:transform type="include" />
>>> <map:transform src="xslt/views/referenceNodeCRUD.xslt" />
>>> <map:serialize type="pretty-xhtml"/>
>>> </map:match>
>>> </map:match>
>>>
>>> As i understand, here is what happens sequentially (didnt plan on sharing this so bear with me)
>>>
>>> GET /html/inc/ReferenceNodeEdit.html
>>> setup serializer
>>> setup transformer node
>>> setup include node
>>> setup generator node
>>> generator reads file
>>> includer parses and calls:
>>> GET servlet:/data/ReferenceTreeNode/root
>>> controller gathers data and returns
>>> GET servlet:/data/done
>>> GET servlet:/gen/UserInfos
>>> INVOKE /gen/UserInfos
>>> GET /gen/SimpleOperation
>>> INVOKE /gen/SimpleOperation
>>> GET /gen/BetwixtControllerModel
>>> INVOKE /gen/BetwixtControllerModel
>>> INVOKE /data/done
>>> INVOKE /data/ReferenceTreeNode/root
>>> transformer starts running and here comes the NPE
>>> 500.xml returned
>>>
>>>
>>> Hope it helps.
>>> Ask if you need anything
>>> Yoann
>>>
>>> On Mon, 2009-03-23 at 14:44 +0100, Steven Dolg wrote:
>>>> Yoann Archambault schrieb:
>>>>> Glad to know i was wrong!
>>>>> It works fine without the xsl:output el.
>>>>>
>>>> Great!
>>>> Glad things are working for you now...
>>>>
>>>> Steven
>>>>> Thanks again!
>>>>> Yoann
>>>>>
>>>>> On Sun, 2009-03-22 at 12:36 -0400, Yoann Archambault wrote:
>>>>>
>>>>>> I do not believe i have an xsl:output elemenet in my stylesheet.
>>>>>> I`ll confirm that when i get home later.
>>>>>> Thanks
>>>>>> Yoann
>>>>>>
>>>>>> On Sun, 22 Mar 2009 14:49 +0100, "Steven Dolg" <st...@indoqa.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Okay, here's what I did.
>>>>>>>
>>>>>>> Sitemap
>>>>>>>
>>>>>>> <map:pipeline>
>>>>>>> <map:match pattern="data/done">
>>>>>>> <map:generate src="bug-fixing/BasicOperationResponse.xml" />
>>>>>>> <map:transform type="include" />
>>>>>>> <map:transform src="bug-fixing/referenceNodeCRUD.xslt" />
>>>>>>> <map:serialize type="xml" />
>>>>>>> </map:match>
>>>>>>> </map:pipeline>
>>>>>>>
>>>>>>> BasicOperationResponse.xml
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <response xmlns:i="http://apache.org/cocoon/3.0/include">
>>>>>>> <i:include src="servlet:/aggregation/sub-request"/>
>>>>>>> <i:include src="servlet:/aggregation/sub-request"/>
>>>>>>> <i:include src="servlet:/aggregation/sub-request"/>
>>>>>>> </response>
>>>>>>>
>>>>>>> (I adjusted the URLs of the includes to something that already existed
>>>>>>> in the sample-app; shouldn't make a difference though)
>>>>>>>
>>>>>>> referenceNodeCRUD.xslt
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>>>>>>> version="1.0">
>>>>>>> <xsl:output method="html"/>
>>>>>>>
>>>>>>> <xsl:template match="/">
>>>>>>> <div>
>>>>>>> <xsl:copy-of select="/response"/>
>>>>>>> </div>
>>>>>>> </xsl:template>
>>>>>>> </xsl:stylesheet>
>>>>>>>
>>>>>>> (just something very primitive)
>>>>>>>
>>>>>>> When I call this pipeline (http:/localhost:8890/data/done) I get just
>>>>>>> the same exception:
>>>>>>>
>>>>>>> <exception-report class="org.apache.cocoon.pipeline.ProcessingException"
>>>>>>> timestamp="Sun, 22 Mar 2009 14:33:39 +0100">
>>>>>>> <message>
>>>>>>> Can't parse url connection
>>>>>>> file:/C:/work/cocoon-3/trunk/cocoon-sample/src/main/resources/COB-INF/bug-fixing/BasicOperationResponse.xml
>>>>>>> </message>
>>>>>>> <stacktrace>
>>>>>>> org.apache.cocoon.pipeline.ProcessingException: Can't parse url
>>>>>>> connection
>>>>>>> file:/C:/work/cocoon-3/trunk/cocoon-sample/src/main/resources/COB-INF/bug-fixing/BasicOperationResponse.xml
>>>>>>> at org.apache.cocoon.sax.util.XMLUtils.toSax(XMLUtils.java:117)
>>>>>>> at
>>>>>>> org.apache.cocoon.sax.component.FileGenerator.execute(FileGenerator.java:81)
>>>>>>> at
>>>>>>> org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:147)
>>>>>>> at
>>>>>>> org.apache.cocoon.pipeline.CachingPipeline.execute(CachingPipeline.java:124)
>>>>>>> at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> However if I remove the "<xsl:output method="html"/>" from the XLST
>>>>>>> everything works fine.
>>>>>>>
>>>>>>> Hope this helps...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Steven
>>>>>>>
>>>>>>>
>>>>>>> Sorry for all this text.
>>>>>>> I wanted to send the files as attachments but last time I did this there
>>>>>>> was a turmoil because some people were afraid their hard disks might
>>>>>>> fill up or something...