commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "matthew.hawthorne" <>
Subject Re: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Sat, 08 May 2004 18:16:32 GMT
robert burrell donkin wrote:
> 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 

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:
For additional commands, e-mail:

View raw message