Keiron Liddle wrote: > > I think the are three possibilities: > - use a generic logging package such as found in avalon, it is quite > possible to use the LogkitLogger, Log4JLogger and Jdk14Logger True, but it introduces a dependency on Yet Another API (YAAPI). I'm generalizing here, but in my experience and from what I've picked up from other people in similar situations, is that keeping YAAPI bloat to a bare minimum is highly desirable. > - use an interface I see this as the most flexible method. > - use methods on the user agent I can see that this approach would provide some flexibility, but I'd suggest that the UA would be useful for obtaining an instance of the logging interface, rather than exposing methods for doing the actual error reporting itself, exactly as it does at the moment. > The interface almost guarantees that we will need extra code to do > things that everyone else is doing. I don't think the amount of extra code would be too great. It would require 2 additional source files right now: one for the interface, one for the default Logkit implementation. Both would be tiny. > We also need to remember context and threading issues. > True. What I have in mind, after getting some sleep in on it, would be to define an interface for all logging, effectively just replacing references org.apache.log.Logger in the existing code with this interface. So getLogger() and setLogger() on Driver, Renderer, etc accept or return objects which implement this interface, for example. I would suggest that this interface look somewhat like a cut down version of org.apache.log.Logger - one that only exposes logging methods such as info(), warn(), error(), etc. For the default implementation we extend org.apache.log.Logger and have the new subclass implement this interface, or provide just provide a wrapper implementation. Lastly, modify Driver (and any other classes which provide default loggers) to instantiate the new default implementation class instead of a Logger, and you're done. For extreme convenience, the interface's logging methods could be identical to those of Logger, so that the default impementation would be extremely basic, and the calls to methods on Logger in existing code would not need to be changed. This mechanism is fast, conveient, and above all, flexible. It means that embedders can write their own, thin implementation of the logging interface and set that on Driver, rather than having to use Avalon and Logkit, but existing users see no change whatsoever, unless they are getting and modifying the default logger provided by Driver or similar. In those cases, it would be a small change to get it working again. If no one has any other objections, I'll whip up a patch for review on the list. 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
