Re: [CLI] new design possibly?

[Nicola Ken Barozzi]

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 <[EMAIL PROTECTED]>
Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]