commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
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 <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.

>
> 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                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

Craig

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