Michael > 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.
Right, I think we agree here. > > 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) I'm exactly proposing this. I suggest you really have a look at Avalon. Avalon is very far from being another large library. Avalon Framework is 46K, LogKit is about 52K. Is that large? Avalon consists of several subprojects (Framework, LogKit, Excalibur, Cornerstone, Phoenix and Applications). Framework is the core which defines some simple contracts. org.apache.avalon.framework.logger.Logger is almost exactly what you did in your proposal, except that you introduce yet another API, while the one from Avalon is mature and already has implementations for LogKit, Log4J, JDK14Logging, Console logging und /dev/null logging. We're talking about reusing mature code. And that sometimes means we have one more jar to include. But what holds us back from extracting the classes we need from avalon-framework.jar and include them in fop.jar. Not very nice, but if it has to be that way... IMO software development today goes more and more in the direction of reusing instead of doing it again and again. You can build big complex application by using several modules and plugging them together. A consequence of that is that we have to get used to add some more jars to our classpaths. That's a small effort when placed against the benefit of reusing mature software. Here's the interface: http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/logger/Logger.html Avalon won't stop at only providing a logging facility. FOP can profit form several components especially in Excalibur by not having to implement its own. For example the Cocoon team is currently moving some components (like SourceResolver) over to Avalon Excalibur. As another FOP could also profit from the use of the caching framework (for images). A big genefit from using Avalon pattern is that it forces you to create cleaner more reusable code. My company has profited a lot from adopting Avalon. I'm disappointed that you're shooting against something you don't know. > > 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. Seems like we agree here. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
