Jeremias Maerki wrote:
> Logging is one thing. Error handling (like layout problems, image that
> can't be found etc.) is another. Right
As much as it at the moment. Obviously, errors need to be reported, and 
the most convenient way to do that is via a logging mechanism. In 
addition, it's often useful if there's some sort of callback mechanism 
so that the application, whether that be Driver or some code embedding 
FOP, can decide how to continue, *if* it should continue, and 
potentially, how to log the error.

Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is 
a convenient and flexible way to go.

> Logging: I'd go for the Avalon Logger interface which lets us freely
> choose the logging backend. We can even use the new ConsoleLogger or
> even NullLogger. :-)

Fair enough, but I maintain that it's still too much work for embedders. 
It is a right pain to have to have to include two more large libraries 
(Avalon and Logkit) with your application just to let FOP do logging, 
and it's too much functionality if your application has it's own logging 
mechanism already.

I'd suggest it would be a poor move to lock FOP into using one 
particular logging mechanism, especially when there are many 
alternatives out there: Log4J, 1.4's native logging mechanism, and all 
the existing, custom jobs, many of which have rabid supporters who won't 
use anything else. 8)

> Error handling: We had a short discussion back in November. Doing that
> in the user agent sounds good (it's the obvious place) although I can't
> fully figure out yet if this solves everything we need. 

I agreee, FOP needs something like the ProblemListener you suggested in 
the thread above.

As I suggested in an earlier email WRT logging, I think the UA is the 
right place to get an instance of an ErrorHandler/ProblemListener, but 
should not itself be responsible for that functionality. What should 
happen (IMHO) is similar to the SAX model:

The application (Driver, or the embedding app) optionally supplies an 
instance of ErrorHandler. If none is supplied, a default instance is 
used which provides resonable default behavior (something like letting 
warnings pass but throwing exceptions for errors). When an error 
condition arises, the code should obtain that instance of ErrorHandler 
from the UA or potentially elsewhere (but it should not just instantiate 
it's own) and invoke the appropriate method on the handler, passing it 
an appropriate exception object. The implementation then decides if it 
is worth throwing that exception, and can do anything else it considers 
worthwhile as well.
Again, with this sort of mechansim, you get flexibility and control, and 
it is very much embedding-friendly.


Michael Gratton <[EMAIL PROTECTED]>
Recall Design <>
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to