Guys,
To further to my suggestions about using an interface for logging in core FOP components, I've produced a working implementation of my suggestion. After a precursory test using the command line, the changes seem to work fine. The patch, for the "fop-0_20_3" branch in CVS, and the two additional required source files are available at: <http://web.vee.net/fop/LoggingHandlerImpl-2002031300.jar> The two added files are src/org/apache/fop/apps/LoggingHandler.java and src/org/apache/fop/apps/LogkitLoggingHandler.java. The former is the LoggingHandler interface, which has replaced any use of org.apache.log.Logger in core FOP code. The latter is an implementation of LoggingHandler which uses Logkit and is Loggable (for Avalon). I've identified three applications which use assume the use of Logkit for logging: The command line app, the FOP task for Ant and TestConverter. All three have been modified to use LogkitLoggingHandler and hence function in the exact same fashion as before. In addition, if no LoggingHandler is explicitly set on Driver, it by default uses an instance of LogkitLoggingHandler, again to make it behave the same as before. Embedders who do not wish to use Logkit for logging can write their own implementation of LoggingHandler and call Driver.setLogger() prior invoking Driver.render(). There are three issues which need to be addressed before I would consider this code ready to commit: - Is the Loggable implementation of LogkitLoggingHandler sufficient for Avalon? Not really knowing how Avalon works, I'm not sure if implementing Loggable on LogkitLoggingHandler is sufficient, or will an "AvalonDriver" subclass of Driver be needed which translates between logging objects be required? Can any Avalon gurus comment on this? - MessageHandler's use of Logger for screen output needs to be fixed. This will probably require a setLoggingHandler() method to be added, and ensuring it gets called prior to MessageHandler getting invoked. - ToBeImplementedProperty grabs a Logger out of thin air, this should probably use MessageHandler or just throw an exception (as outlined in the comments for that class in the patch). Outstanding, non-essential work includes: - Perhaps renaming {get|set}Logger() on Renderer and similar classes to {get|set}LoggingHandler() - Adding optional implementations of LoggingHandler for Log4J, 1.4's logging mechanism, and any others. Please have a look at the patch, try it out applied to the "fop-0_20_3" branch and let me know if you have any suggestions. I'll fix up the three issues above sometime in the next few days and post a new patch. Provided it all works well, would anyone mind having these changes committed to the tree? Thanks, 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