(Sorry for the delay, I've been on "green" holidays again). On 24.03.2004 03:11:16 Glen Mazza wrote: > Team, > > The Cocoon project is starting to move away from > Avalon. Their "building on stone" email thread today > [1], deals with the need to build Cocoon on a solid > framework they have control over, and not on the > framework of another team that is apparently suffering > from high turnover [2]).
It's correct that Avalon has a big problem. I have recently caught myself looking at alternatives though I haven't made up my mind, yet. > Cocoon is higher-level than > FOP [3], so I think what's true for them is doubly > true for us. However, the reasoning applied to Cocoon doesn't necessarily apply to FOP. The parts of Avalon we're currently using are rock-solid. Always were. I've simply never managed to really sit down and do the work to profit from the higher level services (in Excalibur) and start using a container. It seems that I would now have to start yet another crusade to explain why Avalon (or a similar technology) would help in the design of FOP. I simply don't have the time for it and can only send you to the fop-dev archives. > Accordingly, I think it's time now for us to do the > same for FOP. I'd like us to drop the Avalon library > for 1.0, and switch to Jakarta Commons-Logging [4] as > a replacement for Avalon's logging component. As was already hinted Avalon is not only about logging. We're currently using the logging aspect of Avalon and in HEAD I've used Configuration objects to configure some of FOP's components. Dropping Avalon means the Configuration parts no longer work. > For > 1.0, I propose having FOP join Batik, Xalan, Xerces, > AntennaHouse, RenderX, Struts, Axis, and (upcoming) > Cocoon in no longer shipping with Avalon, nor > requiring its users to import that library into their > applications in order to use FOP. Here's my +1. -0 (I don't feel I'm in a position to veto) for now as long as you're only talking about the logging aspect. FOP needs a few things more, as does Cocoon. Simply dropping Avalon doesn't help. If you look at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization you can see that logging is only one item in the requirements list we put together. However, I'm in favor to introduce Commons Logging, at least for certain components in FOP. The PDF library, for example, is a very good example where Avalon-style logging doesn't work very well. Using a static logger there is much more convenient. I had discussions a couple of years back with Nicola Ken Barozzi about the differences between instance-oriented logging (Avalon-style, see below) and static logging (JDK14, Commons Logging, Log4J). Not everything can cleanly be done with Avalon-style logging but it has its advantages. I realize that this means introducing another JAR to the classpath without the (immediate) possibility to get rid of Avalon. But without a reasonable alternative to handle the aspects other than logging I'm against removing Avalon right now. > Commons-logging offers the same type of logger options > [5] that Avalon logging does: The user has a choice > of no logger, stderr logger, Log4J, and JDK 1.4 > logging. They can also create additional logging > types. Correct, but that's not all there is to it. Let me explain: In Avalon-Style logging, you have a Logger interface which is practically the same as all the other Logger interfaces. But what's different in Avalon is the LogEnabled interface that is defines in Avalon Framework. A component implements this interface and gets a Logger instance of the enableLogging(Logger) methods right after instantiation. This is IoC (Inversion of Control, see Avalon documentation for more info) in contrast to static logging where the component actively fetches a logger. One advantage is that you can easily have different logger instances for the same component, for example, if you want to give FOP a different logger for each processing run. I needed that back when I was still using FOP at work. If you just log into a big file in an MT environment you can't find out in a reasonable timeframe which document caused which problem. Logging the thread IDs helps but the output gets totally mixed up. Avalon logging is great and powerful when you're logging from services but it's a PITA when you have code in complex data structures (such as the FO tree) where you would need an instance for the logger for every object instance. > Commons-logging is currently being used by > major open-source applications such as Tomcat, > Tapestry, Apache Axis and Jakarta Struts, and *many* > others [6], so we'll be moving into very good company. Yep. Especially since I'm not ready, yet, to fully accept JDK 1.4 logging. > Another huge advantage I see for FOP in particular is > exceptional integration with Struts applications. For > Struts developers, the same commons-logging instance > that they presently use for their application coding > can be passed into FOP during PDF generation. No more > needing to create a separate Avalon logging instance > in their code, or (possibly) needing to have two > different output logging files, one for each logging > instance. This will look very nice architecturally > for both FOP and Struts. Same is true for integration with Cocoon which is Avalon-based. Cocoon's logger can simply be passed to FOP. (And we don't know, yet, how Cocoon will look like later. For now it's Avalon-based.) > I'll be more than happy to take care of the conversion > for us--I'll make the change via a patch for us to > review before committing. Before Avalon is removed I request a plan be made on how to handle the configuration aspects in FOP. Avalon provides a very good infrastructure to handle this. I've even used it in my Barcode4J project (which is a lot smaller than FOP) because it makes configuring a component using XML a no-brainer. I must say, however, that the Avalon-integration will probably become optional (implemented in special subclasses) as Barcode4J is reasonably simple to work with Bean-style configuration. But still I have absolutely no plans the remove this small dependecy to Avalon Framework. Has anybody here already taken a look at Hivemind (found in Jakarta Commons)? Jeremias Maerki
