cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Q] Returning XSP errors on incorrect use of a logicsheet...
Date Sat, 27 Jul 2002 02:14:03 GMT
Per,

I've implemented better error reporting (see CVS logs). Please try.

Vadim

> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Monday, July 22, 2002 4:50 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: [Q] Returning XSP errors on incorrect use of a
logicsheet...
> 
> > From: Per Kreipke [mailto:per@onclave.com]
> >
> > > > Vadim Gritsenko wrote:
> > > > ...
> > > > > Here is the hint. I guess these two files should be patched:
> > > > > xml-cocoon203\src\java\org\apache\cocoon\components\xslt\
> > > > > XSLTProcessorImpl.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.
> 
> But it does not throw an exception!
> 
> 
> > > IMHO the problem is that the
> > > exception is never propagated (or caught) in the caller during
> > > the transform step.
> 
> Possible bug in Xalan?
> 
> 
> > > 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.
> 
> Exactly. When TraxErrorHandler finds an error, it should throw an
error
> which should be propagated to the initiator of transformation:
> 
>
http://java.sun.com/xml/jaxp/dist/1.1/docs/api/javax/xml/transform/Error
> Listener.html:
>   Throws:
>     TransformerException - if the application chooses to
>     discontinue the transformation.
> 
> 
> I think TraxErrorHandler can buffer all warnings and errors and throw
an
> exception on fatalError. (What is terminate="yes": error or fatal
> error?).
> 
> 
> Vadim
> 
> 
> > Per


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message