commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [CLI] new design possibly?
Date Fri, 07 Feb 2003 21:45:34 GMT

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote:

> Date: Fri, 07 Feb 2003 22:28:24 +0100
> From: Nicola Ken Barozzi <>
> Reply-To: Jakarta Commons Developers List <>
> To:
> 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.

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

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

> --
> Nicola Ken Barozzi         
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------


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

View raw message