> > Vadim Gritsenko wrote:
> > ...
> > > Here is the hint. I guess these two files should be patched:
> > >
> > >
> xml-cocoon203\src\java\org\apache\cocoon\components\xslt\XSLTProcessorIm
> > > pl.java
> > > xml-cocoon203\src\java\org\apache\cocoon\util\TraxErrorHandler.java
> >
> > :-|
> >
> > This is roughly the 10000000002nd time that these get patched for wrong
> > error reporting.
> > Ugh :-S
>
> I don't think the error is actually _in_ there. The TraxErrorHandler is
> correctly handling and reporting the errors. IMHO the problem is that the
> exception is never propagated (or caught) in the caller during
> the transform
> step. Possibly because the XSLT step is being swallowed by the threaded
> transformation (note: can't find that particular code).
>
> Subsequently, the error shows that shows up in the browser ("Error
> compilling foo.xsp: Line 0, column 0: error: java.io.IEException:
> read error
> 1 error") makes perfect sense: the file doesn't exist because the
> Transformer never completed.
>
> The solution is to trap XSLT errors when generating the Java code for the
> XSP. I'm looking at it but another hint would probably speed things up ;-)In particular: ProgramGeneratorImpl.generateResource(...) calls markupLagnuage.generateCode(...); without any try block or checking the return code (maybe it returns a null length string?). So, whatever MarkupLanguage subclass it's calling isn't generating an exception that would get propagated out of generateResource(). If it did, everything might be ok. So I recant my earlier statement, the error could be where Vadim said it was: in the TraxErrorHandler. Onward. Per --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
