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:20:18 GMT
Yep I think these are some of the concerns that will be addressed if we
just test it out.  

If it's bad when using a simple do nothing adapter than we can just junk
the branch.  I can't imagine a call that returns immediately causing too
much of a slow down.  Then again you can guard against the call if the
monitor is null and that would just cost a conditional.  

The good thing is we can run these approaches side by side and let the
benchmarks show us if there really are significant problems.


On Fri, 2004-08-27 at 13:04, Shapira, Yoav wrote:
> Hi,
> If you do convert anything, I for one would be interested in performance
> benchmarks of this monitor approach compared to C-L and to direct
> logging e.g. log4j.  Logging has to be a low-to-negligible performance
> cost component.
> Yoav Shapira
> Millennium Research Informatics
> >-----Original Message-----
> >From: Alex Karasulu []
> >Sent: Friday, August 27, 2004 1:04 PM
> >To: Jakarta Commons Developers List
> >Subject: Re: [general] logging
> >
> >Hiya,
> >
> >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.
> >
> >WDYT?
> >
> >Alex
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged.  This e-mail
is intended only for the individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the sender.  Thank you.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message