Vincent Massol wrote:
>
> ----- Original Message -----
> From: "James Strachan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 01, 2001 11:18 AM
> Subject: Re: LOG4J
>
> > > >Log4j is such a difficult package to use.
> > >
> > > 2 for 2. Ask youself why most projects that use log4j, use it behind a
> > > fascade. Wrapping it behind a fascade goes against the use case that
> > > everyone uses (see libc on most platforms and they have some sort of
> > syslog
> > > or ntlog style functionality). What would be your answer to this?
> >
> > I just had a quick look at the JSR and it looks like the package is going
> to
> > be java.util.logging (rather than javax.logging) so that rules out using
> the
> > JSR until you're sure all your users have moved to Merlin JDK 1.4 :-(
> >
> > So how about we add a simple, lightweight facade component for logging to
> > jakarta-commons?
> >
> > Somewhere between 1 and 4 classes would probably do. Nothing fancy or too
> > clever, just an easy to use, abstract Facade which is fairly similar to a
> > subset of the JSR functionality. Probably include a simple simple
> > implementation that just logs to a file or System.out that is used by
> > default if no other implementation is configured. So simple, small and
> > lightweight. Ideal for any project no matter how small (assuming some
> > logging facility is required ;-)
> >
> > Then bindings to the JSR implementation, logj4 and possibly logkit could
> be
> > done and plugged in. If a project wants a more powerful logging mechanism
> > they can plugin, say, log4j or logkit or the JSR.
> >
> > Something along the lines of a subset of the JSR would be quite easy to do
> > in a small number of simple classes:-
> >
>
> 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 ...
> 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, ... 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).
Wouldn't this be an appropriate thing for log4j to do (or to contribute
to log4j) ?
> - Make it a rule that if some component of commons need to do logging, it
> has to use Log4j.
>
> Is that too restrictive ? Thoughts ?
Yes, I think that's too restrictive. I think this is one of those
evolutionary things - if a component needs to log, it would be up to the
component, and if the users of that component find that it's appropriate
to add log4j capability, it will happen.
Maybe trying to define a commons logging interface is worthwhile, but
also, I think that evolution might resolve that question over time as
well.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
