(Carlos I have cc'd you since this is a good "best pratice" for debugging)
On Thursday 03 January 2002 03:49 pm, you wrote:
> 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.
Ah, I went through the hell that is debugging RuntimeException's that occur
in the SAX stream. My solution,
Wrap *all* SAX event handlers that you have written (or think may be buggy)
ala:
public void endElement(String uri, String loc, String raw) throws SAXException
{
try {
//your code here
} catch (RuntimeException re) {
throw new SAXException("RuntimeException in endElement", re);
}
}
and you will find the error. Once I figured this trick out I used it in a few
choice spots and fixed all my errors. (well, not *ALL* just the RE's in the
SAX stream :)
-pete
--
peter royal -> [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
