commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [general] logging
Date Fri, 27 Aug 2004 17:04:15 GMT

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 [mailto:aok123@bellsouth.net]
>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:
>
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message