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. Mike. -- Michael Gratton <[EMAIL PROTECTED]> Recall Design <http://www.recalldesign.com/> s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555
smime.p7s
Description: S/MIME Cryptographic Signature