You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/09/18 00:29:17 UTC
Logging framework
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 ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm just thinking about one interface (org.apache.cxf.common.logging.Logger)
and a default implementation that uses java.util.logging or whatever if we
want to switch to something else.
SLF4J seems to be the next JCL without the drawbacks, so why not... I
don't have a strong need for using slf4j or JCL or any other api. I just
want to be able to switch the underlying implementation when integrating cxf
in another product.
On 9/18/07, James Mao <ja...@iona.com> wrote:
>
> I don't know how much code we'll maintain, if it's just a few classes,
> i guess it's ok,
> otherwise i think a third party dependency is better,
> looks like a lot of apache projects using it,
> I also found jetty v6 is on the list
>
> James
>
> > This is a possibility. I don't know if people want to avoid
> > a third party library dependency...
> > Jetty for example has its own Logger interface that can be
> > easily implemented.
> > See
> >
> http://svn.jetty.codehaus.org/browse/jetty/jetty/trunk/modules/util/src/main/java/org/mortbay/log
> >
> > On 9/18/07, James Mao <ja...@iona.com> wrote:
> >
> >> Something like this http://www.slf4j.org/?
> >>
> >> James
> >>
> >>
> >>> 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 ?
> >>>
> >>>
> >>>
> >
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Logging framework
Posted by James Mao <ja...@iona.com>.
I don't know how much code we'll maintain, if it's just a few classes,
i guess it's ok,
otherwise i think a third party dependency is better,
looks like a lot of apache projects using it,
I also found jetty v6 is on the list
James
> This is a possibility. I don't know if people want to avoid
> a third party library dependency...
> Jetty for example has its own Logger interface that can be
> easily implemented.
> See
> http://svn.jetty.codehaus.org/browse/jetty/jetty/trunk/modules/util/src/main/java/org/mortbay/log
>
> On 9/18/07, James Mao <ja...@iona.com> wrote:
>
>> Something like this http://www.slf4j.org/?
>>
>> James
>>
>>
>>> 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 ?
>>>
>>>
>>>
>
>
>
>
Re: Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
This is a possibility. I don't know if people want to avoid
a third party library dependency...
Jetty for example has its own Logger interface that can be
easily implemented.
See
http://svn.jetty.codehaus.org/browse/jetty/jetty/trunk/modules/util/src/main/java/org/mortbay/log
On 9/18/07, James Mao <ja...@iona.com> wrote:
>
> Something like this http://www.slf4j.org/?
>
> James
>
> > 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 ?
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Logging framework
Posted by James Mao <ja...@iona.com>.
Something like this http://www.slf4j.org/?
James
> 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 ?
>
>
Fwd: Fwd: Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Sep 18, 2007 5:24 PM
Subject: Re: Fwd: Logging framework
To: Daniel Kulp <dk...@apache.org>
On 9/18/07, Daniel Kulp <dkulp@apache.org > wrote:
>
>
>
> > * nobody use Logger.setLevel() in the code
>
> Why? Log4j certainly supports it. You would just need to do:
See below. The underlying log framework can be reconfigured at runtime.
> * the new Logger implementation has to override all the log, logp,
> > logrb, entering, exiting, throwing, severe, warning, info, config,
> > fine, finer, finest, addHandler methods (they all check the level
> > before calling log, so you need to bypass these checks)
>
> You probably wouldn't need to. In the constructor, do something like:
>
> public Log4JLogger(....) {
> super(...);
> log4jLogger = ........
> super.setLevel(mapToJUL(log4jLogger.getEffectiveLevel()));
> }
>
> so the level that they are comparing to is the appropriate one. They
> would then only need to override the log(LogRecord) method.
But log4j supports dynamic reconfiguration which is very very handy when
you want to debug an existing application. ServiceMix does that for
example,
and I've seen other products where you can configure the log levels through
JMX. This means that you can not check the level when the logger is
created.
Hence the need to override all the methods.
> As a class inside cxf/commons with log4j as an optional dependency ?
> > But if we go this way, i would rather wrap slf4j so that a user can
> > easily choose its own logging framework.
>
> Well, slf4j has it's own issues. It doesn't support the ResourceBundle
> stuff that we completely rely on. It also has one less logging level,
> but not a huge deal.
Anyway, I guess both implementations would be roughly similar.
Dan
>
>
>
> > Sounds like creating a pluggable logging framework that would use
> > java.util.logging as an api ? What a nice idea ;-)
> > But if that's the way to go ... I'll write it.
> >
> >
> > 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
>
>
>
> --
> 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/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Fwd: Logging framework
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 18 September 2007, Guillaume Nodet wrote:
> On 9/18/07, Daniel Kulp <dk...@apache.org> wrote:
> > 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.
>
> It will work provided that:
> * everybody use LogUtils.createl7nLogger() method
Which is easily enforced with Checkstyle. Not a big deal.
> * nobody use Logger.setLevel() in the code
Why? Log4j certainly supports it. You would just need to do:
public void setLevel(Level l) {
super.setLevel(l);
log4jLogger.setLevel(mapToL4j(l));
}
> * nobody use Logger.addHandler()
Or the log4j wrapper can wrap the handlers with whatever it needs and do
the right thing. First impl could probably ignore it (or throw
UnsupportedOperation) as I doubt it's called anywhere.
> * the new Logger implementation has to override all the log, logp,
> logrb, entering, exiting, throwing, severe, warning, info, config,
> fine, finer, finest, addHandler methods (they all check the level
> before calling log, so you need to bypass these checks)
You probably wouldn't need to. In the constructor, do something like:
public Log4JLogger(....) {
super(...);
log4jLogger = ........
super.setLevel(mapToJUL(log4jLogger.getEffectiveLevel()));
}
so the level that they are comparing to is the appropriate one. They
would then only need to override the log(LogRecord) method.
> As a class inside cxf/commons with log4j as an optional dependency ?
> But if we go this way, i would rather wrap slf4j so that a user can
> easily choose its own logging framework.
Well, slf4j has it's own issues. It doesn't support the ResourceBundle
stuff that we completely rely on. It also has one less logging level,
but not a huge deal.
Dan
> Sounds like creating a pluggable logging framework that would use
> java.util.logging as an api ? What a nice idea ;-)
> But if that's the way to go ... I'll write it.
>
>
> Dan
>
> > On Tuesday 18 September 2007, Guillaume Nodet wrote:
> > > ---------- Forwarded message ----------
> > > From: Guillaume Nodet <gn...@gmail.com>
> > > Date: Sep 18, 2007 9:14 AM
> > > Subject: Re: Logging framework
> > > To: Daniel Kulp <dk...@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 <dk...@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
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Fwd: Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
On 9/18/07, Daniel Kulp <dk...@apache.org> wrote:
>
>
>
> 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.
It will work provided that:
* everybody use LogUtils.createl7nLogger() method
* nobody use Logger.setLevel() in the code
* nobody use Logger.addHandler()
* the new Logger implementation has to override all the log, logp, logrb,
entering, exiting, throwing, severe, warning, info, config, fine, finer,
finest, addHandler methods (they all check the level before calling log, so
you need to bypass these checks)
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.
I guess every commit is disruptive ;-)
Refactoring should be a way to get CXF better and better...
But i still don't see any technical reasons for not using an interface that
we would define. It would just make a clean separation so that each project
/ user does not have to write the same thing again and again. We could even
have no performance hit by using the same api than java.util.logging (or a
compatible one) and make our Logger implementation that just implement this
interface. Just remove the setLevel / addHandler method and we're done.
In anycase, I can stub that out for log4j later today if you want.
As a class inside cxf/commons with log4j as an optional dependency ?
But if we go this way, i would rather wrap slf4j so that a user can easily
choose its own logging framework.
Sounds like creating a pluggable logging framework that would use
java.util.logging as an api ? What a nice idea ;-)
But if that's the way to go ... I'll write it.
Dan
>
>
> On Tuesday 18 September 2007, Guillaume Nodet wrote:
> > ---------- Forwarded message ----------
> > From: Guillaume Nodet <gn...@gmail.com>
> > Date: Sep 18, 2007 9:14 AM
> > Subject: Re: Logging framework
> > To: Daniel Kulp <dk...@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 <dk...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Fwd: Logging framework
Posted by Daniel Kulp <dk...@apache.org>.
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 <gn...@gmail.com>
> Date: Sep 18, 2007 9:14 AM
> Subject: Re: Logging framework
> To: Daniel Kulp <dk...@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 <dk...@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
Fwd: Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Sep 18, 2007 9:14 AM
Subject: Re: Logging framework
To: Daniel Kulp <dk...@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 <dk...@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/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Logging framework
Posted by Daniel Kulp <dk...@apache.org>.
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