cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Fwd: Logging framework
Date Tue, 18 Sep 2007 11:19:02 GMT


Guillaume,

It really IS that simple.   All of the create logger calls go through 
LogUtils.createl7nLogger, thus, the issue of the factory is irrelevant.   
Those methods become the factory.    In the log4j impl, it creates a 
subclass of Logger that wraps the log4j logger and forwards the log and 
isLoggable methods to the log4j versions.   It's very simple to do.   
Lars had it stubbed May 2006 for Yoko.

The "mixes concern like logging and configuration" part is irrelevant 
from my standpoint.   The target logging platform should also map those 
if they care about them.   In anycase, I'm -1 to changing logging API's 
throughout the code.   It's very disruptive and for no gain if the above 
works. 

In anycase, I can stub that out for log4j later today if you want.

Dan


On Tuesday 18 September 2007, Guillaume Nodet wrote:
> ---------- Forwarded message ----------
> From: Guillaume Nodet <gnodet@gmail.com>
> Date: Sep 18, 2007 9:14 AM
> Subject: Re: Logging framework
> To: Daniel Kulp <dkulp@apache.org>
>
> I thought about that.
> The only problem is that Logger is a class and its own factory
> (thanks for extensibility design).  It also mixes concern like
> logging and configuration.  Keeping the Logger class does not
> ensure which methods are used in the CXF code base.
> We can implement our own LogManager to create our derived
> Logger, but this is a system global variable to configure, which
> means it has side effect on all the VM :-(
> Also, it does not work because the LogManager is initialized
> only once when the logging system is initialized, which means
> that when CXF is loaded, it may already be too late to set our
> own LogManager.
> I wish your idea could work, that would be much easier...
>
> On 9/18/07, Daniel Kulp <dkulp@apache.org> wrote:
> > Guillaume,
> >
> > All creation of Logger	objects now go through the
> > LogUtils.createL7nLogger(...) calls.   Thus, IMO, you should just
> > update those two methods to wrapper things like Log4j with something
> > that implements the Logger interface and return that.   That would
> > be the lowest impact on existing code, we could all still use the
> > j.u.l API's, etc... (except we need to make sure to create the
> > loggers through LogUtils, which we should anyway for i18n reasons.)
> >
> >
> >
> > Dan
> >
> > On Monday 17 September 2007, Guillaume Nodet wrote:
> > > It seems CXF logging uses java.util.logging, which is fine
> > > for a standalone product, but not so fine when integrating CXF
> > > inside another product (thinking about geronimo, servicemix,
> > > etc...). The main problem is that lots of products uses log4j or
> > > another logging mechanism, and not being able to integrate and use
> > > the same logging mechanism is imho a real pain for users who want
> > > to debug and see what happens.
> > >
> > > I'm thinking about creating a interface
> > > org.apache.cxf.common.logging.Logger that would be used instead of
> > > the java.util.logging.Logger class.  The LogUtils
> > > helper class would reuse a default implementation using
> > > java.util.logging, while other products could implement their own
> > > version to wrap their preferred logging api.
> > >
> > > Thoughts ?
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727    C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message