I'm using Cocoon2.0rc2
The stacktrace is bogus in that the original exception was orginally
(partial stacktrace from cocoon.log)
DEBUG (2002-01-02) 17:58.45:743 [cocoon ]
(/cocoon/ods/CompileMessageDoc) Thread-26/CachingStreamPipeline: Exception
in process
java.lang.RuntimeException
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1112)
at TaminoGenerator.generate(TaminoGenerator.java:55)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process
.
.
.
The exception was pointing to the parse() method of my Generator
(TaminoGenerator), and all indications were that the problem was there. The
fact that the problem really lay two steps later in the pipeline (after an
XSLT transform in the XInclude transformer) is certainly not obvious from
the stack trace. The resolution involved recompiling Xerces with debugging
on to print the original source of the exception which resulted in...
java.lang.RuntimeException: stargazer
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3170)
at
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerH
andlerImpl.java:433)
at
org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:48)
at
org.apache.xerces.parsers.SAXParser.endDocument(SAXParser.java:1230)
at
org.apache.xerces.validators.common.XMLValidator.callEndDocument(XMLValidato
r.java:1146)
at
org.apache.xerces.framework.XMLDocumentScanner$EndOfInputDispatcher.dispatch
(XMLDocumentScanner.java:1499)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.
java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
at TaminoGenerator.generate(TaminoGenerator.java:55)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEv
entPipeline.java:210)
Which gave my a clue (solely by virtue of the reference to xalan) that the
problem may not be in my generator, but rather further down the pipeline. I
then began eliminating subsequent steps in the pipeline until I had isolated
the exception to the XInclude transformer. Then I began looking at the
XIncludeTransformer.java, where I discovered the code requiring the use of
the base attribute in the first few lines of the processXIncludeElement()
method (~line 220). I then added the base attribute to my source XML
document, put everything back together and it worked.
I still don't know what caused the runtime exception. I just got a better
idea of where it was being generated (in the endDocument() handler).
This is certainly not a criticism of the XInclude transformer, but it is an
indication of how difficult it can be to troubleshoot Cocoon.
-Mitch
PS Here is my sitemap snippet.
<!-- ========================= Reconstitute Message Documents - Mitch
========================= -->
<map:match pattern="ods/CompileMessageDoc">
<map:generate type="tamino">
<map:parameter name="dburl" value="http://dbhost/tamino/db/"/>
<map:parameter name="collection" value="docs"/>
<map:parameter name="xpath" value="/Message[@ino:id=271]"/>
</map:generate>
<map:transform type="xslt"
src="http://stargazer/tamino/microwarehouse/maps/map/CompileMessage.xsl"/>
<map:transform type="xinclude"/>
<map:serialize type="xml"/>
</map:match>
-----Original Message-----
From: John Morrison [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 03, 2002 11:40 AM
To: [EMAIL PROTECTED]
Subject: RE: XInclude and base attribute
Which version are you using?
> -----Original Message-----
> From: Mitchell Christensen [mailto:[EMAIL PROTECTED]]
<snip/> :) (sorry, another thread)
> If no 'base' (http://www.w3.org/TR/xmlbase/) attribute is
> specified within a
> document to be processed by the XInclude transformer, the XInclude
> transformer assumes that the href value within the <xi:include/>
> element is
> a relative filename, and prepends the installation directory path ahead of
> the href value. Unfortunately, I was using a full URL to an XML document
> (accessed via HTTP), and was getting a runtime exception. The runtime
> exception was happening because the XInclude transformer was turning
> 'http://myhost/mydoc' into
> '/usr/local/tomcat/webapps/cocoon/http://myhost/mydoc'. This
> resulted in a
> silent runtime exception, with no diagnostics and a couple of
> days to figure
<snip/>
> In retrospect, the lack of the xmlbase documentation was less of a problem
> than the fact the Cocoon thew an obtuse runtime exception with a bogus
> stacktrace.
How was the stacktrace bogus?
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
