commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [general] logging
Date Fri, 27 Aug 2004 17:03:43 GMT

BTW before I begin I wanted to say that C-L is simple and costs
relatively little.  It does not tie a library to a logging
implementation and IMHO it gets far too much criticism for the
convenience it affords us.  Its really an **adapter** for other logging
implementations and that's it (as Craig pointed out below).  Perhaps its
the fact that this is a dependency on another jar that causes this issue
to come up repeatedly as opposed to logging itself.  In the end I don't
know exactly why it is such a hot topic of debate. 

However I think this issue is one we can resolve if we generalize the
problem using monitors and event notification.  Logging is just a
specific application for a monitor. Paul Hammant described this in the
NoLogging wiki here:

I think I brought this up before and forgive me for doing it again.  If
this is annoying anyone I will not discuss it again.  Perhaps I need the
cons against it once more.  However I still do believe that this is the
best solution for now.

All a library needs to do is expose a monitor interface to publish the
notible events that may occur while the library is doing its thang.  How
the monitor responds to events by logging them or otherwise is a matter
of implementation.  A default do-nothing monitor adapter may be packaged
with the library instead of the dependency on C-L.  Other monitor
interface implementations, not packaged with the core, can have a C-L
based logging monitor implementation (hence C-L dependency) that can be
used out of the box if desired.  Dependencies are minimized, ugly
logging code is isolated away and all the parties concerned are happy. 
Is this too idealistic a viewpoint?  Perhaps.  I guess I'm offering up
this approach yet again for others to correct me.

On Thu, 2004-08-26 at 17:17, Craig McClanahan wrote:
> You are asking two separate but related quesitons here, so they should
> be addressed separately.
> (1) Should libraries depend on *any* logging library?

I believe there should be no dependency at all although I'm comfortable
with a dep on C-L.  People just get too passionate about dependencies
now adays.  So why not get rid of the argument by solving all these
concerns.  The use of a callback monitor interface exposed by these
libraries would solve the need for any C-L or other dependencies.  Plus
by generalizing the problem we open the door for many more use cases.

> (2) If so, what logging library should be used?

I don't think (1) has to be the case but if it were C-L IMO would be the
absolute best choice for the reasons you've stated below:

> * Log4J -- but this would force all downstream users of the
>   library to use Log4J, even if the applications themseves
>   use something else.
> * JDK 1.4 -- but this would force all downstream users of
>   the library to run on JDK 1.4, and also doesn't obey the
>   "single logging configuration" desire if they are using
>   something like Log4J
> * The same basic issue will apply to any other individual
>   logging implementation you might like -- the selection
>   of a particular logging API by a commonly reused library
>   *forces* applications using that library to support that
>   logging API, even if the app is using something different.
> Indeed, this issue was the motivation for creating Commons Logging in
> the first place -- instead of being a logging *implementation* it was
> deliberately designed as an *adapter* to whatever underlying
> implementation you want to use.  

Yes this has been said over and over again and I don't understand why
the debate re-emerges.  Again I can only suspect that its the required
jar dependecy that is causing most of the concern out there.

> So, what is it that you are suggesting?

I would like to add to this.  Is the root of our concerns really the
fact that we have a dependency on another library or is the issue here
about a dependency on a logging implemenation?

If the answer to this Q is yes, the concern is the additional dependency
and not on a logging adapter or implementation, then using monitors is
the way to go.  It will do away with the dependency.  Meanwhile it will
still allow for these libraries to notify users of significant events
occuring in the library.  If users choose they can then wire up the
library to a specific logging monitor.  The user still gets to decide in
the end.  

To help demonstrate the application of this NoLogging approach I'm
volunteering myself to any commons project to convert their C-L
dependency into a monitor with an associated adapter and other logging
implementations.  We can make the changes in a branch.  When complete we
can take a step back to look and see if this approach is worth it.  If
not we can scratch the idea.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message