funnily enough, if commons logging was to be created again, i'd (with hindsight) consider something along those lines. the bridging implementations would be in a separate, optional jar and the two classes required in the public logging API would be copied over into each component (as part of the build). if the implementation jar is not present, error and fatal levels (only) would log to system.err. those users wanting logging would have to grab and drop in the implementation jar.
Here's my opinion on the best approach to logging for each component:
Each component creates a simple interface for logging (which could just be a
copy of o.a.c.l.Log copied into the components namespace, becoming, for example,
o.a.c.beanutils.Log)
The component also creates a LogFactory, which checks if commons logging is in
the classpath. If it is, it returns an implementation which delegates to commons-logging.
If it isn't, it just sends messages of the appropriate level to system.err (just like robert suggests).
This may sound a bit complicated, but it's really not. To me, this is a good example of how to
deal with optional dependencies. In this example, [beanutils] functions fine without
commons-logging, but adding commons-logging to the classpath enhances the logging capabilities.
The only problem would be that beanutils would have to invoke the commons-logging methods
through reflection, since making the calls directly would result in a compile-time dependency
on commons-logging. This would slow things down a bit.
Is this reasonable, or too much work?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
