> Hey Jeremias, > > Jeremias Maerki wrote: > > > > Right, I think we agree here. > > > > Cool.
;-) > > 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? > > Okay, my "two large libraries" remark was off-centre, but you really > need to consider those who, for whatever reason, simply *can't* use > Avalon. The reasons may be technical, political or otherwise, but if FOP > forces people to use Avalon, then you will end up having people who > won't use FOP because of it. Ok, let's look at it that way: With your reasoning people who *can't* use Avalon *can't* use Cocoon, for example. But Cocoon only uses Avalon internally. Externally, it exposes its functionality as a Servlet, for example. So when you use the WAR file you don't use Avalon directly. You only edit some XML-based configuration files that happen to be loaded by Avalon. What I want to say is the following: FOP users don't necessarily have to fiddle with Avalon since we can provide non-avalon interfaces for the outside world. We've had that discussion on the list a few days ago. So we get to the point of being able to use Avalon's facilities (only those we need such as logging for the time being and probably more later). Those who want to use a different logging facility can simply use one of Avalon's implementations or write their own. Actually, your proposal and mine are exactly the same except that I'd like to use existing code. You introduce more FOP-specific stuff that we have to maintain and support. Hey, look at it that way. FOP uses Batik for SVG. They have their own URIResolver. FOP has its own code for URI resolving. Cocoon (which uses FOP) has its URI resolver that's being moved to Avalon Excalibur. And they're all under the same hood (ASF). Ugly story. When we introduce your logging idea (It's a good one I just happen to think there's a better one) we start something like that again. > I'd love to have the time to get to know Avalon, but I just don't. In > addition, the there is no way the particular project here at work I want > to embed FOP in is going to use Avalon. Period. If the dependency on > Avalon can't be broken, then there's very little chance FOP will be used > for this project. Which I'll find very dissapointing, because I'm a big > fan of FOP. I guess you still think Avalon is some big mammoth that will get in your way. I don't think so, and the guys from Avalon would be too glad to prove you the opposite. No, really. If all that you're after is logging and you can live with an additional jar in the classpath, then Avalon will not get in your way. It may even spare you of writing your own logger adapter. You can even remove logkit.jar because it won't be needed. > > > org.apache.avalon.framework.logger.Logger is almost exactly what you did > > in your proposal, except that you introduce yet another API, > > Okay, in it's defence, the LoggingHandler API is very small, being one > interface large. As is org.apache.avalon.framework.logger.Logger. > The LogkitLoggingHandler class provides a transparent > wrapper for using Logkit and Avalon with FOP. Avalon is no logger. It has logger facilities exactly for the same reason that we need one for FOP. So why don't we use Avalon's? > For existing applications, > such as the command line app, it took (IIRC) one extra line and changing > three others to use the LoggingHandler mechanism, and it still uses > Logkit for the logging. If you want to use your own logger, then just > wrap it in a LogkitLoggingHandler and away you go. The amount of > additional work required to use the new interface is absolutely minimal, > and it will still work with Avalon, most likely by changing one single > line of code or configuration. That would mean LoggingHandler wraps Avalon's Logger interface which in turns wraps Logkit, Log4J, JDK14Logger etc. No benefit here, I think. > > > We're talking about reusing mature code. And that sometimes means we have one > > more jar to include. > > I'm not talking about throwing it all away - you can still use all of > that existing code if you want. And sometimes one more jar is one too many. I wouldn't trade in code reuse for a reduced number of jars. When this is really a problem you can always repack jars, so fop.jar, for example, includes the things needed from Avalon. (as I already said). > > I'm disappointed that you're shooting against something you don't know. > > > > I'll be the first to admit that I'm not familiar with Avalon, but I do > know I can't use it every project, even if I had the time to learn about > it, and I also know that if you start making core FOP functionality > depend on external services such as Avalon, a lot of embedders will go > elsewehre. You don't need to learn Avalon. Really! We can use Avalon internally. We can use Avalon's Logger interface and we can document how you plug in another logger implementation. IT WILL BE EASY! > > Seems like we agree here. > > > > What I don't understand is how you can agree with using something like > ErrorHandler but be against using a LoggingHandler, which works > *precisely* in the same way. It's the *exact* same mechanism, but for > logging. Because Avalon's Logger interface is almost exactly the same as yours. And because we don't have to reinvent the wheel. Trust me, I'd be the first to agree with your proposal would Avalon not exist. > If it still works with Avalon and Logkit, and works for embedders, how > can you lose from such a win-win situation? My proposal has the same benefits but with less code on the FOP-side. Granted, we (may) have one more jar (avalon-framework.jar) but when we want to use Avalon some more (Caching, URI Resolving etc) we have to include it anyway (ok, probabaly another one: avalon-excalibur.jar). And FOP can concentrate on layout.... 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]
