Hi folks!
Over at the DeltaSpike we are discussing about a generic logging layer which we
can exchange easily.
We have been reluctant to use slf4j because some containers use different
layers etc. But jul is also not really satisfying.
It should be easily shadeable and use java6 features like
Would there be some interest for creating a commons-logging-2.0?
I had some code for CL2 version. Basically commons 1.x but without the
detection logic.
So you pick the implementation by having the right jar in the
classpath. Not sure I still have it.
At some stage I just gave up. Mostly
You could look at the Log4j 2 API, but while it supports multiple
implementations, is really designed to be an abstraction layer so that
user's have a clear line between the API and implementation. For the time
being you can find the documentation at
http://people.apache.org/~rgoers/log4j2/.
hi guys,
you have the full support also from my side, a fresh new era of
commons-components has to born.
I am +1 to work on a commons-logging-2.0. It's clobberin' time!
all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
- Original Message -
From: ralph.goers @dslextreme.com ralph.go...@dslextreme.com
To: Commons Developers List dev@commons.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Wednesday, February 8, 2012 8:20 PM
Subject: Re: any plans for commons-logging-2.0?
You could look
On Wed, Feb 8, 2012 at 1:06 PM, Mark Struberg strub...@yahoo.de wrote:
Hi Ralph!
I took a pretty deep look into log4j-2.0 already (even used it for a few
sample projects). But I was not aware that it's also an abstraction
layer/facade ^^
So by using log4j-2.0 in DeltaSpike, a container
Sorry to ask a bit naive, but does cl2.0 make sense with log4j 2.0 in
mind? It seems log4j 2.0 does have such an abstraction and there is
slf4j too. Probably it is time to go dormant instead?
Anyway, if there are some reasons to continue working I would welcome
Torstens approach of course! Not
Anyway, if there are some reasons to continue working I would welcome
Torstens approach of course! Not that I want to take out the
enthusiasm here
I am also not sure it's worth the effort TBH.
FWIW: for libraries I ended up usually having no logging dependency at
all and for projects I just
