commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Problems with commons-logging
Date Sun, 03 Feb 2002 10:24:24 GMT
On Sat, 2 Feb 2002, Remy Maucherat wrote:

> > Both log4j and logkit have solutions that allow safe use in a container
> > environment, i.e. support of isolation for the users of the API
> > ( one app using the package can't mess with another app's logging ).
> > I'm -1 on releasing with this whole in it.
> You can always hide it in the core of the container. And the SM will protect
> you :)
> I agree it may be a problem in some cases, but it won't be for Tomcat.

Don't overestimate the SM. If the logger is successfull and a lot of
components will depend on it, it's very likely it'll end up in the common
class loader ( or even the system loader ), at least in some
configurations. Even if tomcat's class loader may protect a bit ( and
I doubt that), many other applications don't have such a xxxxx class

Remember all the problems and mess with jaxp in tc - the code is extremely
tricky if you don't want jaxp in the common loader. Not too many people
can understand how it works and when it works.

> I don't see a problem with getInstance, though. What's the problem ?
> Using getInstance, or just constructing the object with a new seems
> equivalent to me.

Creating a new object may be different - getInstance may give you the
logger that is already used by a different application.

> > - static methods in LogSource. I suppose LogSource is a sort of
> > factory - the pattern used here is completely unnatural ( or at least
> > different from most APIs in use ).
> Static everywhere, actually ;-)
> There's some syncing needed in there, also (the loggers are in a HashMap).

Yes. I don't mind 1-2 static methods ( preferably in Log ), for
convenience, but they should just be a shortcut for calling a virtual
method in the log manager.

> > - Given that it is a facade, it would need some way to pass at least
> > config info to the underlying logger ( at least setProperty like ).
> > Some logger may not need any, but if they do it'll require using
> > internal APIs.
> I don't see very well how to configure the logger either. In Catalina and
> Slide, we just instantiate the logger directly, so there's no such problem.

I just hate the config mechanism for log4j - a system property is
a nightmare in a container env ( with multiple apps, etc ), and a
properties file in classes/ is not very nice ( by my taste ). I would
prefer a file in conf/ or etc/ or constructed from the component
'natural' config.

Passing at least a basic piece of config to the logger is essential,
it doesn't have to be supported by all loggers.

> > - no support for i18n-style messages. Probably not a big deal
> > for the first release, but it would be nice to think about it ( I know
> > log4j can do that, I assume other as well ).
> You mean have the logger handle the message bundle for you, and just give it
> the message key (+ params) ?

That would be a good idea. One possible optimization for the logger would
be to store the unprocessed key/params, and have them processed off line
( or just have an efficient way to generate the message ). StringBundle
has some issues.


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

View raw message