commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [CLI] new design possibly?
Date Fri, 07 Feb 2003 22:03:00 GMT


Craig R. McClanahan wrote, On 07/02/2003 22.45:
> 
> On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote:
> 
> 
>>Date: Fri, 07 Feb 2003 22:28:24 +0100
>>From: Nicola Ken Barozzi <nicolaken@apache.org>
>>Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>>To: commons-dev@jakarta.apache.org
>>Subject: Re: [CLI] new design possibly?
>>
>>
>>Craig R. McClanahan wrote, On 07/02/2003 18.23:
>>
>>>On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote:
>>>
>>>>Looks like an AOP-like system to intercept all logs of a package could
>>>>help, but I'm lost here.
>>>>
>>>If you implement your own LogFactory, this is pretty straightforward,
>>>since it is your LogFactory instance that creates all the Log instances
>>>(even those declared static).
>>
>>What if other packages decide to make their factory? Can I somehow be
>>sure that I'm the top one deciding things?
> 
> Ultimately, the person deploying the application makes an explicit choice
> of which factory class wins.  You could, I suppose, design a log factory
> that was itself a wrapper around an arbitrary other LogFactory
> implementation -- if so, you'd configure both the choice of your wrapper
> as the "official" factory for commons-logging to use, and how it kwnows
> what other factory should be wrapped.

Ok, so it all comes down to how I configure it right?

>>Also, what about different classloaders. Would a single LogFactory work
>>with all of them?
> 
> That's a really important question, especially in things like a servlet
> container.  The current implementation of LogFactory.getFactory()
> configures a LogFactory instance per class loader.  It also has support
> for using the thread context class loader to make this determination,
> instead of the class loader used to load commons-logging itself.  This
> makes things work nicely in an environment like Tomcat, where you can have
> the API classes (commons-logging-api.jar) in a shared parent class loader,
> yet allow each app (loaded by a separate child class loader) configure its
> own LogFactory and logging configuration.

How are they configured? (excuse my ignorance)

>>Just trying to understand better.
>>
>>
>>>I once had to integrate some libraries using commons-logging into an app
>>>that wanted to funnel log messages into logs (in the underlying
>>>environment) with different names than those used by the calling packages.
>>>This was accomplished by a trivially simple LogFactory implementation that
>>>performed the log name mapping and delegated to the existing impl for the
>>>work of actually creating the instance.
>>>
>>>The same approach would work (for example) to return a Log instance that
>>>was decorated AOP-style with extra functionality.
>>
>>Hmmm, seems cool.
>>
>>
>>>No, it's not the strict IOC pattern that Avaloners really like.  But
>>>there's more than one useful design pattern in the world, and the factory
>>>create pattern is pretty popular too :-).
>>
>>Yes, and speaking personally (not too loud ;-) I use it too with things
>>that are not coarse-grained components.
> 
> :-)
> 
>>Is simply does not make sense to
>>micromanage every logger and handle it to all children IMHO.
> 
> One of the things I like about the way commons-logging is commonly used
> today (declaring an instance or static variable per-using-class) is that
> you *don't* have to configure anything, or remember to call setLogger() to
> avoid NPEs.  It "just works" (tm), automatically adapting to how you've
> configured commons-logging, with no per-object configuration required.

Sometimes it's just to easy though, and you get more logging that you 
would want.

The bottom line is that I want to be sure in an easy way that no logging 
is performed, unless requested.

logging.properties has caused headaches to many, I'm wondering if it's 
the right thing/way to pursue.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
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