Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <412F8DFF.1090009@apache.org>
Date: Fri, 27 Aug 2004 12:39:43 -0700
From: "matthew.hawthorne" <matth@apache.org>
User-Agent: Mozilla Thunderbird 0.7 (X11/20040615)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [general] logging
References: <Pine.LNX.4.44.0408261637180.6228-100000@orinoco.flamefew.net>
	 <f8b39ace0408261417854f2c1@mail.gmail.com>
 <1093626223.1581.54.camel@fermi.trunk.joshua-tree.org>
 <f8b39ace04082712137e0caa9d@mail.gmail.com>
In-Reply-To: <f8b39ace04082712137e0caa9d@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Craig McClanahan wrote:
> On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <aok123@bellsouth.net> wrote:
> 
>>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
>> 
> The problem I have with this general approach is that it trades a
> dependency on a logging adapter for a requirement to create code that
> responds to the individual event handling interface for every single
> library I'm using.  

This is only a requirement if you have a need to get details about what
the library is doing.  In most cases, I don't -- but I obviously can't 
speak for
everyone else.

Logging (via commons-logging) has become pretty much a standard part
of development for me.  But for those for which this is not the case,
I don't see implementing a simple monitor interface to handle events
as much harder than putting log4j into the classpath, setting up
the config file to log for the desired class, etc.  Either way requires 
some extra work.


> The primary benefit of having all the libraries
> conform to a common logging API (whatever it is) is *precisely* the
> fact that I, as an application developer, don't have to go through
> that kind of pain -- I just configure the logging levels and
> destinations, using my favorite logging implementation (using a single
> log for everything, separate logs for functional areas, requesting the
> appropriate amount of detail on a global or local level, or whatever
> else I want), and it just works.

I guess I always saw the primary benefit and purpose of commons-logging 
to be
a bit simpler than this.  I thought it was to allow libraries to log, 
while allowing the user
to choose which logging library is used -- nothing more.

However, what you've said may indeed be true -- the issue is whether 
what works best
for you works best for everyone else.  I'm fine with everything using 
commons-logging,
but that's because I use it in pretty much every project I'm on anyway. 
  For others,
it may cause more of an inconvenience, although I'm not quite sure how. 
  Too many jars, maybe.


> My concern can be dealt with by implementing a commone event monitor
> API that all the libraries use, so that I can still implement a
> generic event listening framework ... but isn't that, in spirit
> (although not in the proposed implementation manner), exactly what
> commons-logging already does?

Very true -- but I don't think this is what anyone was proposing.
If this was the idea, then, just as you've said, I think commons-logging 
does the job fine.

No need for commons-monitor or anything weird like that...

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org