----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
> The problem is that you have 2 choices. Either you abstract the full
logging
> API (including Formatting of messages, Categories, Appenders,
Configuration,
> ...) and then you're fine but you do the same heavy work as the JSR is
doing
> or you only abstract a few APIs like log.debug(), log.warning(), ... but
> then you're stuck if you wish to use the Categories of Log4j for example
...
The Logger class in the JSR is pretty similar to that of the Categories of
Log4J. You can look them up by name and they behave fairly similarly. So
what I'm really saying is we make a facade interface to Categories (log4j)
and Logger (JSR). Focussing only on the really core features that we need to
do.
// JSR / or commons logging API
private static Logger logger = Logger.get( "foo.bar" );
// Log4J
private static Category logger = Category.get( "foo.bar" );
>From an API perspective, we don't need Appenders, Configuration or any of
that stuff in the commons project - that can be plugged in 'around the
back' - its deployment configuration details.
I just want a simple API like log4j's Categories or like the JSR's Logger -
they are very similar. If we abstracted just that into our own API it would
be easy to integrate with either the JSR or log4j.
> You'll then have to use Log4j directly without going through your
> abstraction classes because you need some special initialization, the
> methods do not have the same needed input parameters, ...
>
> I would prefer to do the following :
> - write 2-3 asbtraction classes *for* Log4j, i.e. it is used as a
> developer's guideline and methodology. Like for example standardizing on
> using the full class name as logging Categories,
I agree - I'd prefer to pass in the Class object like this...
private static Logger logger = Logger.get( Foo.class );
or
private Logger logger = Logger.get( this );
I just used Strings as it was more familiar.
> ... The real intent of
> these abstraction classes are just to make sure all the commons packages
use
> it in the same manner as much as possible (so that it is easier to
> understand the code and moving it to the Logging JSR later on will all be
> easier).
Agreed. Though the only part of the JSR or log4j API I want in the commons
project is that of actually performing simple logging operations. Nothing to
do with formatting, appenders, configurations or other such nice to haves.
> - Make it a rule that if some component of commons need to do logging, it
> has to use Log4j.
>
> Is that too restrictive ? Thoughts ?
I'd rather allow either log4j or the JSR. They are quite similar afterall.
And the proposed Logger class is pretty simple anyway - it would be easy to
integrate with both log4j and the JSR.
I don't think we need very much from the 'Logger' interface in the commons
project, just enough to do some basic logging.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
