You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2013/07/24 09:56:51 UTC
[DBCP] DBCP2 and logging
I'm working my way through the open DBCP bugs with a view to getting the
DBCP code (and the POOL code as some changes may be required there) into
a state where it is ready for the first v2 release.
I've quickly reached DBCP-154 that requests that logging is added. This
is not a new request and goes back to DBCP-4 and possibly earlier. From
memory there are a number of open DBCP bugs that require some form of
logging. There are also lots of places where DBCP logs directly to
stdout or stderr.
This quickly brings us to the point of having to decide which logging
framework to use. This is largely the same debate we had for POOL [1]
but with a few key differences:
- there are many more places where logging is required
- there are many more places where logging could be useful
Because of the volume of logging, I don't believe the JMX approach used
for POOL is viable for DBCP.
Therefore, I intend to go ahead and add a dependency on Commons-Logging.
Mark
[1] http://markmail.org/message/zuufedzkfx62v5eq
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, libxxx is a particular usage. When i said more used i qpoke about apps
and was speaking about feedbacks i got from TomEE and work.
Le 24 juil. 2013 23:24, "Emmanuel Bourg" <eb...@apache.org> a écrit :
> Le 24/07/2013 18:53, Romain Manni-Bucau a écrit :
>
> > about "slf4j is better supported": since it is more widely used (i don't
> > judge)
>
> http://qa.debian.org/popcon.php?package=libcommons-logging-java
>
> http://qa.debian.org/popcon.php?package=libslf4j-java
>
> You said? :)
>
> Emmanuel Bourg
>
>
>
Re: [DBCP] DBCP2 and logging
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 24/07/2013 18:53, Romain Manni-Bucau a écrit :
> about "slf4j is better supported": since it is more widely used (i don't
> judge)
http://qa.debian.org/popcon.php?package=libcommons-logging-java
http://qa.debian.org/popcon.php?package=libslf4j-java
You said? :)
Emmanuel Bourg
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@gary: yes but since slf4j is designed as an API that's more logical (but
not important for this thread)
about "slf4j is better supported": since it is more widely used (i don't
judge) and it is easier to isolate slf4j it is generally easier to use
slf4j (i particularly speak of TomEE case but i saw it on some more
containers)
the main issue of CL was the classloader handling (last time i tested with
1.1.1). I agree we can still hack it but since there are alternative i
don't see the need (+ other containers will probably not do)
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Gary Gregory <ga...@gmail.com>
> On Wed, Jul 24, 2013 at 12:36 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > Hmm SLF4J as backend? i'd have thought to the opposite but this way is
> > weird.
> >
>
> That is supported too: SLF4J as the API and Log4j 2 as the back-end.
>
> Gary
>
> >
> > about CL issue it is mainly the fact few containers isolate it correctly
> > from the apps (on this point slf4j is better supported)
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/24 Gary Gregory <ga...@gmail.com>
> >
> > > While still in Beta, there is also Log4j 2, which let's you optionally
> > use
> > > SLF4J as the back-end.
> > >
> > > Gary
> > >
> > >
> > > On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
> > > wrote:
> > >
> > > > On 7/24/13 12:56 AM, Mark Thomas wrote:
> > > > > I'm working my way through the open DBCP bugs with a view to
> getting
> > > the
> > > > > DBCP code (and the POOL code as some changes may be required there)
> > > into
> > > > > a state where it is ready for the first v2 release.
> > > > >
> > > > > I've quickly reached DBCP-154 that requests that logging is added.
> > This
> > > > > is not a new request and goes back to DBCP-4 and possibly earlier.
> > From
> > > > > memory there are a number of open DBCP bugs that require some form
> of
> > > > > logging. There are also lots of places where DBCP logs directly to
> > > > > stdout or stderr.
> > > > >
> > > > > This quickly brings us to the point of having to decide which
> logging
> > > > > framework to use. This is largely the same debate we had for POOL
> [1]
> > > > > but with a few key differences:
> > > > > - there are many more places where logging is required
> > > > > - there are many more places where logging could be useful
> > > > >
> > > > > Because of the volume of logging, I don't believe the JMX approach
> > used
> > > > > for POOL is viable for DBCP.
> > > > >
> > > > > Therefore, I intend to go ahead and add a dependency on
> > > Commons-Logging.
> > > >
> > > > First, many thanks for jumping back in!
> > > >
> > > > I have two basic questions:
> > > >
> > > > 1) Do we absolutely need logging itself or is there some other way
> > > > we could satisfy the needs here? IIRC, there are basically two
> > > > things that "require" logging in DBCP: a) abandoned connections b)
> > > > exceptions / warnings. In a), we want users to be able to log the
> > > > stack trace of the code that opened the connection. Case b) splits
> > > > into all kinds of different stuff. This may be a little smelly, but
> > > > I wonder if we could not shove what is really needed in normal
> > > > operations into JMX properties (which would just hold information
> > > > from recent messages) and support a debug mode where things get
> > > > spewed as today to System.err or a configured LogWriter.
> > > >
> > > > 2) Are there any real reasons that commons-logging will not meet the
> > > > need? I have read the other messages on this thread and have not
> > > > seen a concrete reason, other than "others like slf2j better." Have
> > > > we in fact definitively resolved the classloader-related issues that
> > > > used to make commons-logging a bad choice?
> > > >
> > > > If the answer to 1) is we absolutely need logging and 2) comes down
> > > > to a matter of taste, I am +1 on commons-logging because I agree
> > > > with the dogfood argument and also do-ocracy ;)
> > > >
> > > > Phil
> > > > >
> > > > > Mark
> > > > >
> > > > >
> > > > > [1] http://markmail.org/message/zuufedzkfx62v5eq
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > > .
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [DBCP] DBCP2 and logging
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jul 24, 2013 at 12:36 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hmm SLF4J as backend? i'd have thought to the opposite but this way is
> weird.
>
That is supported too: SLF4J as the API and Log4j 2 as the back-end.
Gary
>
> about CL issue it is mainly the fact few containers isolate it correctly
> from the apps (on this point slf4j is better supported)
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/24 Gary Gregory <ga...@gmail.com>
>
> > While still in Beta, there is also Log4j 2, which let's you optionally
> use
> > SLF4J as the back-end.
> >
> > Gary
> >
> >
> > On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
> > wrote:
> >
> > > On 7/24/13 12:56 AM, Mark Thomas wrote:
> > > > I'm working my way through the open DBCP bugs with a view to getting
> > the
> > > > DBCP code (and the POOL code as some changes may be required there)
> > into
> > > > a state where it is ready for the first v2 release.
> > > >
> > > > I've quickly reached DBCP-154 that requests that logging is added.
> This
> > > > is not a new request and goes back to DBCP-4 and possibly earlier.
> From
> > > > memory there are a number of open DBCP bugs that require some form of
> > > > logging. There are also lots of places where DBCP logs directly to
> > > > stdout or stderr.
> > > >
> > > > This quickly brings us to the point of having to decide which logging
> > > > framework to use. This is largely the same debate we had for POOL [1]
> > > > but with a few key differences:
> > > > - there are many more places where logging is required
> > > > - there are many more places where logging could be useful
> > > >
> > > > Because of the volume of logging, I don't believe the JMX approach
> used
> > > > for POOL is viable for DBCP.
> > > >
> > > > Therefore, I intend to go ahead and add a dependency on
> > Commons-Logging.
> > >
> > > First, many thanks for jumping back in!
> > >
> > > I have two basic questions:
> > >
> > > 1) Do we absolutely need logging itself or is there some other way
> > > we could satisfy the needs here? IIRC, there are basically two
> > > things that "require" logging in DBCP: a) abandoned connections b)
> > > exceptions / warnings. In a), we want users to be able to log the
> > > stack trace of the code that opened the connection. Case b) splits
> > > into all kinds of different stuff. This may be a little smelly, but
> > > I wonder if we could not shove what is really needed in normal
> > > operations into JMX properties (which would just hold information
> > > from recent messages) and support a debug mode where things get
> > > spewed as today to System.err or a configured LogWriter.
> > >
> > > 2) Are there any real reasons that commons-logging will not meet the
> > > need? I have read the other messages on this thread and have not
> > > seen a concrete reason, other than "others like slf2j better." Have
> > > we in fact definitively resolved the classloader-related issues that
> > > used to make commons-logging a bad choice?
> > >
> > > If the answer to 1) is we absolutely need logging and 2) comes down
> > > to a matter of taste, I am +1 on commons-logging because I agree
> > > with the dogfood argument and also do-ocracy ;)
> > >
> > > Phil
> > > >
> > > > Mark
> > > >
> > > >
> > > > [1] http://markmail.org/message/zuufedzkfx62v5eq
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > > .
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DBCP] DBCP2 and logging
Posted by Phil Steitz <ph...@gmail.com>.
On 7/24/13 9:36 AM, Romain Manni-Bucau wrote:
> Hmm SLF4J as backend? i'd have thought to the opposite but this way is
> weird.
>
> about CL issue it is mainly the fact few containers isolate it correctly
> from the apps (on this point slf4j is better supported)
What exactly do you mean by "slf4j is better supported?" The
containers isolate it better? Also, for the containers that do not
isolate it correctly, what is the marginal impact of adding it as a
dependency to DBCP? Do these containers bundle DBCP as well and not
isolate it? What I am trying to understand is what practical impact
it would have if we added c-l as a DBCP dependency?
Phil
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/24 Gary Gregory <ga...@gmail.com>
>
>> While still in Beta, there is also Log4j 2, which let's you optionally use
>> SLF4J as the back-end.
>>
>> Gary
>>
>>
>> On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
>> wrote:
>>
>>> On 7/24/13 12:56 AM, Mark Thomas wrote:
>>>> I'm working my way through the open DBCP bugs with a view to getting
>> the
>>>> DBCP code (and the POOL code as some changes may be required there)
>> into
>>>> a state where it is ready for the first v2 release.
>>>>
>>>> I've quickly reached DBCP-154 that requests that logging is added. This
>>>> is not a new request and goes back to DBCP-4 and possibly earlier. From
>>>> memory there are a number of open DBCP bugs that require some form of
>>>> logging. There are also lots of places where DBCP logs directly to
>>>> stdout or stderr.
>>>>
>>>> This quickly brings us to the point of having to decide which logging
>>>> framework to use. This is largely the same debate we had for POOL [1]
>>>> but with a few key differences:
>>>> - there are many more places where logging is required
>>>> - there are many more places where logging could be useful
>>>>
>>>> Because of the volume of logging, I don't believe the JMX approach used
>>>> for POOL is viable for DBCP.
>>>>
>>>> Therefore, I intend to go ahead and add a dependency on
>> Commons-Logging.
>>> First, many thanks for jumping back in!
>>>
>>> I have two basic questions:
>>>
>>> 1) Do we absolutely need logging itself or is there some other way
>>> we could satisfy the needs here? IIRC, there are basically two
>>> things that "require" logging in DBCP: a) abandoned connections b)
>>> exceptions / warnings. In a), we want users to be able to log the
>>> stack trace of the code that opened the connection. Case b) splits
>>> into all kinds of different stuff. This may be a little smelly, but
>>> I wonder if we could not shove what is really needed in normal
>>> operations into JMX properties (which would just hold information
>>> from recent messages) and support a debug mode where things get
>>> spewed as today to System.err or a configured LogWriter.
>>>
>>> 2) Are there any real reasons that commons-logging will not meet the
>>> need? I have read the other messages on this thread and have not
>>> seen a concrete reason, other than "others like slf2j better." Have
>>> we in fact definitively resolved the classloader-related issues that
>>> used to make commons-logging a bad choice?
>>>
>>> If the answer to 1) is we absolutely need logging and 2) comes down
>>> to a matter of taste, I am +1 on commons-logging because I agree
>>> with the dogfood argument and also do-ocracy ;)
>>>
>>> Phil
>>>> Mark
>>>>
>>>>
>>>> [1] http://markmail.org/message/zuufedzkfx62v5eq
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> .
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
for sure since it bothers a bunch of people, doing a superb library which
is not usable is useless
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/25 Benedikt Ritter <br...@apache.org>
> 2013/7/24 Romain Manni-Bucau <rm...@gmail.com>
>
> > Hmm SLF4J as backend? i'd have thought to the opposite but this way is
> > weird.
> >
> > about CL issue it is mainly the fact few containers isolate it correctly
> > from the apps (on this point slf4j is better supported)
> >
>
> Is this lack in container implementations really a problem dbcp should be
> concerned with?
>
>
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/24 Gary Gregory <ga...@gmail.com>
> >
> > > While still in Beta, there is also Log4j 2, which let's you optionally
> > use
> > > SLF4J as the back-end.
> > >
> > > Gary
> > >
> > >
> > > On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
> > > wrote:
> > >
> > > > On 7/24/13 12:56 AM, Mark Thomas wrote:
> > > > > I'm working my way through the open DBCP bugs with a view to
> getting
> > > the
> > > > > DBCP code (and the POOL code as some changes may be required there)
> > > into
> > > > > a state where it is ready for the first v2 release.
> > > > >
> > > > > I've quickly reached DBCP-154 that requests that logging is added.
> > This
> > > > > is not a new request and goes back to DBCP-4 and possibly earlier.
> > From
> > > > > memory there are a number of open DBCP bugs that require some form
> of
> > > > > logging. There are also lots of places where DBCP logs directly to
> > > > > stdout or stderr.
> > > > >
> > > > > This quickly brings us to the point of having to decide which
> logging
> > > > > framework to use. This is largely the same debate we had for POOL
> [1]
> > > > > but with a few key differences:
> > > > > - there are many more places where logging is required
> > > > > - there are many more places where logging could be useful
> > > > >
> > > > > Because of the volume of logging, I don't believe the JMX approach
> > used
> > > > > for POOL is viable for DBCP.
> > > > >
> > > > > Therefore, I intend to go ahead and add a dependency on
> > > Commons-Logging.
> > > >
> > > > First, many thanks for jumping back in!
> > > >
> > > > I have two basic questions:
> > > >
> > > > 1) Do we absolutely need logging itself or is there some other way
> > > > we could satisfy the needs here? IIRC, there are basically two
> > > > things that "require" logging in DBCP: a) abandoned connections b)
> > > > exceptions / warnings. In a), we want users to be able to log the
> > > > stack trace of the code that opened the connection. Case b) splits
> > > > into all kinds of different stuff. This may be a little smelly, but
> > > > I wonder if we could not shove what is really needed in normal
> > > > operations into JMX properties (which would just hold information
> > > > from recent messages) and support a debug mode where things get
> > > > spewed as today to System.err or a configured LogWriter.
> > > >
> > > > 2) Are there any real reasons that commons-logging will not meet the
> > > > need? I have read the other messages on this thread and have not
> > > > seen a concrete reason, other than "others like slf2j better." Have
> > > > we in fact definitively resolved the classloader-related issues that
> > > > used to make commons-logging a bad choice?
> > > >
> > > > If the answer to 1) is we absolutely need logging and 2) comes down
> > > > to a matter of taste, I am +1 on commons-logging because I agree
> > > > with the dogfood argument and also do-ocracy ;)
> > > >
> > > > Phil
> > > > >
> > > > > Mark
> > > > >
> > > > >
> > > > > [1] http://markmail.org/message/zuufedzkfx62v5eq
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > > .
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [DBCP] DBCP2 and logging
Posted by Benedikt Ritter <br...@apache.org>.
2013/7/24 Romain Manni-Bucau <rm...@gmail.com>
> Hmm SLF4J as backend? i'd have thought to the opposite but this way is
> weird.
>
> about CL issue it is mainly the fact few containers isolate it correctly
> from the apps (on this point slf4j is better supported)
>
Is this lack in container implementations really a problem dbcp should be
concerned with?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/24 Gary Gregory <ga...@gmail.com>
>
> > While still in Beta, there is also Log4j 2, which let's you optionally
> use
> > SLF4J as the back-end.
> >
> > Gary
> >
> >
> > On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
> > wrote:
> >
> > > On 7/24/13 12:56 AM, Mark Thomas wrote:
> > > > I'm working my way through the open DBCP bugs with a view to getting
> > the
> > > > DBCP code (and the POOL code as some changes may be required there)
> > into
> > > > a state where it is ready for the first v2 release.
> > > >
> > > > I've quickly reached DBCP-154 that requests that logging is added.
> This
> > > > is not a new request and goes back to DBCP-4 and possibly earlier.
> From
> > > > memory there are a number of open DBCP bugs that require some form of
> > > > logging. There are also lots of places where DBCP logs directly to
> > > > stdout or stderr.
> > > >
> > > > This quickly brings us to the point of having to decide which logging
> > > > framework to use. This is largely the same debate we had for POOL [1]
> > > > but with a few key differences:
> > > > - there are many more places where logging is required
> > > > - there are many more places where logging could be useful
> > > >
> > > > Because of the volume of logging, I don't believe the JMX approach
> used
> > > > for POOL is viable for DBCP.
> > > >
> > > > Therefore, I intend to go ahead and add a dependency on
> > Commons-Logging.
> > >
> > > First, many thanks for jumping back in!
> > >
> > > I have two basic questions:
> > >
> > > 1) Do we absolutely need logging itself or is there some other way
> > > we could satisfy the needs here? IIRC, there are basically two
> > > things that "require" logging in DBCP: a) abandoned connections b)
> > > exceptions / warnings. In a), we want users to be able to log the
> > > stack trace of the code that opened the connection. Case b) splits
> > > into all kinds of different stuff. This may be a little smelly, but
> > > I wonder if we could not shove what is really needed in normal
> > > operations into JMX properties (which would just hold information
> > > from recent messages) and support a debug mode where things get
> > > spewed as today to System.err or a configured LogWriter.
> > >
> > > 2) Are there any real reasons that commons-logging will not meet the
> > > need? I have read the other messages on this thread and have not
> > > seen a concrete reason, other than "others like slf2j better." Have
> > > we in fact definitively resolved the classloader-related issues that
> > > used to make commons-logging a bad choice?
> > >
> > > If the answer to 1) is we absolutely need logging and 2) comes down
> > > to a matter of taste, I am +1 on commons-logging because I agree
> > > with the dogfood argument and also do-ocracy ;)
> > >
> > > Phil
> > > >
> > > > Mark
> > > >
> > > >
> > > > [1] http://markmail.org/message/zuufedzkfx62v5eq
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > > .
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm SLF4J as backend? i'd have thought to the opposite but this way is
weird.
about CL issue it is mainly the fact few containers isolate it correctly
from the apps (on this point slf4j is better supported)
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Gary Gregory <ga...@gmail.com>
> While still in Beta, there is also Log4j 2, which let's you optionally use
> SLF4J as the back-end.
>
> Gary
>
>
> On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com>
> wrote:
>
> > On 7/24/13 12:56 AM, Mark Thomas wrote:
> > > I'm working my way through the open DBCP bugs with a view to getting
> the
> > > DBCP code (and the POOL code as some changes may be required there)
> into
> > > a state where it is ready for the first v2 release.
> > >
> > > I've quickly reached DBCP-154 that requests that logging is added. This
> > > is not a new request and goes back to DBCP-4 and possibly earlier. From
> > > memory there are a number of open DBCP bugs that require some form of
> > > logging. There are also lots of places where DBCP logs directly to
> > > stdout or stderr.
> > >
> > > This quickly brings us to the point of having to decide which logging
> > > framework to use. This is largely the same debate we had for POOL [1]
> > > but with a few key differences:
> > > - there are many more places where logging is required
> > > - there are many more places where logging could be useful
> > >
> > > Because of the volume of logging, I don't believe the JMX approach used
> > > for POOL is viable for DBCP.
> > >
> > > Therefore, I intend to go ahead and add a dependency on
> Commons-Logging.
> >
> > First, many thanks for jumping back in!
> >
> > I have two basic questions:
> >
> > 1) Do we absolutely need logging itself or is there some other way
> > we could satisfy the needs here? IIRC, there are basically two
> > things that "require" logging in DBCP: a) abandoned connections b)
> > exceptions / warnings. In a), we want users to be able to log the
> > stack trace of the code that opened the connection. Case b) splits
> > into all kinds of different stuff. This may be a little smelly, but
> > I wonder if we could not shove what is really needed in normal
> > operations into JMX properties (which would just hold information
> > from recent messages) and support a debug mode where things get
> > spewed as today to System.err or a configured LogWriter.
> >
> > 2) Are there any real reasons that commons-logging will not meet the
> > need? I have read the other messages on this thread and have not
> > seen a concrete reason, other than "others like slf2j better." Have
> > we in fact definitively resolved the classloader-related issues that
> > used to make commons-logging a bad choice?
> >
> > If the answer to 1) is we absolutely need logging and 2) comes down
> > to a matter of taste, I am +1 on commons-logging because I agree
> > with the dogfood argument and also do-ocracy ;)
> >
> > Phil
> > >
> > > Mark
> > >
> > >
> > > [1] http://markmail.org/message/zuufedzkfx62v5eq
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > .
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [DBCP] DBCP2 and logging
Posted by Gary Gregory <ga...@gmail.com>.
While still in Beta, there is also Log4j 2, which let's you optionally use
SLF4J as the back-end.
Gary
On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 7/24/13 12:56 AM, Mark Thomas wrote:
> > I'm working my way through the open DBCP bugs with a view to getting the
> > DBCP code (and the POOL code as some changes may be required there) into
> > a state where it is ready for the first v2 release.
> >
> > I've quickly reached DBCP-154 that requests that logging is added. This
> > is not a new request and goes back to DBCP-4 and possibly earlier. From
> > memory there are a number of open DBCP bugs that require some form of
> > logging. There are also lots of places where DBCP logs directly to
> > stdout or stderr.
> >
> > This quickly brings us to the point of having to decide which logging
> > framework to use. This is largely the same debate we had for POOL [1]
> > but with a few key differences:
> > - there are many more places where logging is required
> > - there are many more places where logging could be useful
> >
> > Because of the volume of logging, I don't believe the JMX approach used
> > for POOL is viable for DBCP.
> >
> > Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>
> First, many thanks for jumping back in!
>
> I have two basic questions:
>
> 1) Do we absolutely need logging itself or is there some other way
> we could satisfy the needs here? IIRC, there are basically two
> things that "require" logging in DBCP: a) abandoned connections b)
> exceptions / warnings. In a), we want users to be able to log the
> stack trace of the code that opened the connection. Case b) splits
> into all kinds of different stuff. This may be a little smelly, but
> I wonder if we could not shove what is really needed in normal
> operations into JMX properties (which would just hold information
> from recent messages) and support a debug mode where things get
> spewed as today to System.err or a configured LogWriter.
>
> 2) Are there any real reasons that commons-logging will not meet the
> need? I have read the other messages on this thread and have not
> seen a concrete reason, other than "others like slf2j better." Have
> we in fact definitively resolved the classloader-related issues that
> used to make commons-logging a bad choice?
>
> If the answer to 1) is we absolutely need logging and 2) comes down
> to a matter of taste, I am +1 on commons-logging because I agree
> with the dogfood argument and also do-ocracy ;)
>
> Phil
> >
> > Mark
> >
> >
> > [1] http://markmail.org/message/zuufedzkfx62v5eq
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > .
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Let's go for that, just ensure to test all cases - app/server, app only,
server only ...- (i can help for that) before the release.
Le 24 juil. 2013 19:42, "Gary Gregory" <ga...@gmail.com> a écrit :
> Also, for JCL we can fix things nice and quick.
>
> Gary
>
> On Jul 24, 2013, at 13:29, Mark Thomas <ma...@apache.org> wrote:
>
> > On 24/07/2013 17:15, Phil Steitz wrote:
> >
> >> 1) Do we absolutely need logging itself or is there some other way
> >> we could satisfy the needs here? IIRC, there are basically two
> >> things that "require" logging in DBCP: a) abandoned connections b)
> >> exceptions / warnings. In a), we want users to be able to log the
> >> stack trace of the code that opened the connection. Case b) splits
> >> into all kinds of different stuff. This may be a little smelly, but
> >> I wonder if we could not shove what is really needed in normal
> >> operations into JMX properties (which would just hold information
> >> from recent messages) and support a debug mode where things get
> >> spewed as today to System.err or a configured LogWriter.
> >
> > It is the smelliness I am trying to avoid. I think that was OK for pool
> > as there was very few places where we needed to log stuff. DBCP has many
> > more places and my view is that there are enough of them to do it
> properly.
> >
> >> 2) Are there any real reasons that commons-logging will not meet the
> >> need? I have read the other messages on this thread and have not
> >> seen a concrete reason, other than "others like slf2j better." Have
> >> we in fact definitively resolved the classloader-related issues that
> >> used to make commons-logging a bad choice?
> >
> > I haven't come across any for a while but that doesn't mean there aren't
> > some there somewhere.
> >
> > If we use JCL then those that support the dogfood argument can do so and
> > those that prefer SLF4J can just drop JCL and use the SLF4J replacement.
> > There might be an issue with dependencies in the pom for that approach
> > but I hope the Maven experts can identify a solution for that.
> >
> > Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by Gary Gregory <ga...@gmail.com>.
Also, for JCL we can fix things nice and quick.
Gary
On Jul 24, 2013, at 13:29, Mark Thomas <ma...@apache.org> wrote:
> On 24/07/2013 17:15, Phil Steitz wrote:
>
>> 1) Do we absolutely need logging itself or is there some other way
>> we could satisfy the needs here? IIRC, there are basically two
>> things that "require" logging in DBCP: a) abandoned connections b)
>> exceptions / warnings. In a), we want users to be able to log the
>> stack trace of the code that opened the connection. Case b) splits
>> into all kinds of different stuff. This may be a little smelly, but
>> I wonder if we could not shove what is really needed in normal
>> operations into JMX properties (which would just hold information
>> from recent messages) and support a debug mode where things get
>> spewed as today to System.err or a configured LogWriter.
>
> It is the smelliness I am trying to avoid. I think that was OK for pool
> as there was very few places where we needed to log stuff. DBCP has many
> more places and my view is that there are enough of them to do it properly.
>
>> 2) Are there any real reasons that commons-logging will not meet the
>> need? I have read the other messages on this thread and have not
>> seen a concrete reason, other than "others like slf2j better." Have
>> we in fact definitively resolved the classloader-related issues that
>> used to make commons-logging a bad choice?
>
> I haven't come across any for a while but that doesn't mean there aren't
> some there somewhere.
>
> If we use JCL then those that support the dogfood argument can do so and
> those that prefer SLF4J can just drop JCL and use the SLF4J replacement.
> There might be an issue with dependencies in the pom for that approach
> but I hope the Maven experts can identify a solution for that.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/2013 17:15, Phil Steitz wrote:
> 1) Do we absolutely need logging itself or is there some other way
> we could satisfy the needs here? IIRC, there are basically two
> things that "require" logging in DBCP: a) abandoned connections b)
> exceptions / warnings. In a), we want users to be able to log the
> stack trace of the code that opened the connection. Case b) splits
> into all kinds of different stuff. This may be a little smelly, but
> I wonder if we could not shove what is really needed in normal
> operations into JMX properties (which would just hold information
> from recent messages) and support a debug mode where things get
> spewed as today to System.err or a configured LogWriter.
It is the smelliness I am trying to avoid. I think that was OK for pool
as there was very few places where we needed to log stuff. DBCP has many
more places and my view is that there are enough of them to do it properly.
> 2) Are there any real reasons that commons-logging will not meet the
> need? I have read the other messages on this thread and have not
> seen a concrete reason, other than "others like slf2j better." Have
> we in fact definitively resolved the classloader-related issues that
> used to make commons-logging a bad choice?
I haven't come across any for a while but that doesn't mean there aren't
some there somewhere.
If we use JCL then those that support the dogfood argument can do so and
those that prefer SLF4J can just drop JCL and use the SLF4J replacement.
There might be an issue with dependencies in the pom for that approach
but I hope the Maven experts can identify a solution for that.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by James Carman <jc...@carmanconsulting.com>.
On Jul 26, 2013, at 8:22 PM, sebb <se...@gmail.com> wrote:
>
> So long as the docs make very clear that the listener must complete
> quickly, I don't see why DBCP should have to take additional
> precautions.
> Indeed it might be useful for debugging if the listener were synchronous.
>
I'm cool with that. We should also take care to make the no-op case (no listeners registered) as fast as possible, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by sebb <se...@gmail.com>.
On 27 July 2013 00:24, James Carman <ja...@carmanconsulting.com> wrote:
> Perhaps an event listener for all dbcp events? Then folks can log it
> themselves. I would be concerned about performance unless of course the
> events are delivered asynchronously.
So long as the docs make very clear that the listener must complete
quickly, I don't see why DBCP should have to take additional
precautions.
Indeed it might be useful for debugging if the listener were synchronous.
> On Wednesday, July 24, 2013, Phil Steitz wrote:
>
>> On 7/24/13 12:56 AM, Mark Thomas wrote:
>> > I'm working my way through the open DBCP bugs with a view to getting the
>> > DBCP code (and the POOL code as some changes may be required there) into
>> > a state where it is ready for the first v2 release.
>> >
>> > I've quickly reached DBCP-154 that requests that logging is added. This
>> > is not a new request and goes back to DBCP-4 and possibly earlier. From
>> > memory there are a number of open DBCP bugs that require some form of
>> > logging. There are also lots of places where DBCP logs directly to
>> > stdout or stderr.
>> >
>> > This quickly brings us to the point of having to decide which logging
>> > framework to use. This is largely the same debate we had for POOL [1]
>> > but with a few key differences:
>> > - there are many more places where logging is required
>> > - there are many more places where logging could be useful
>> >
>> > Because of the volume of logging, I don't believe the JMX approach used
>> > for POOL is viable for DBCP.
>> >
>> > Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>>
>> First, many thanks for jumping back in!
>>
>> I have two basic questions:
>>
>> 1) Do we absolutely need logging itself or is there some other way
>> we could satisfy the needs here? IIRC, there are basically two
>> things that "require" logging in DBCP: a) abandoned connections b)
>> exceptions / warnings. In a), we want users to be able to log the
>> stack trace of the code that opened the connection. Case b) splits
>> into all kinds of different stuff. This may be a little smelly, but
>> I wonder if we could not shove what is really needed in normal
>> operations into JMX properties (which would just hold information
>> from recent messages) and support a debug mode where things get
>> spewed as today to System.err or a configured LogWriter.
>>
>> 2) Are there any real reasons that commons-logging will not meet the
>> need? I have read the other messages on this thread and have not
>> seen a concrete reason, other than "others like slf2j better." Have
>> we in fact definitively resolved the classloader-related issues that
>> used to make commons-logging a bad choice?
>>
>> If the answer to 1) is we absolutely need logging and 2) comes down
>> to a matter of taste, I am +1 on commons-logging because I agree
>> with the dogfood argument and also do-ocracy ;)
>>
>> Phil
>> >
>> > Mark
>> >
>> >
>> > [1] http://markmail.org/message/zuufedzkfx62v5eq
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
>> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>> >
>> > .
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 27/07/2013 00:24, James Carman wrote:
> Perhaps an event listener for all dbcp events? Then folks can log it
> themselves. I would be concerned about performance unless of course the
> events are delivered asynchronously.
My initial reaction was - neat idea lets do it.
However, on further reflection I'm not convinced this helps much in the
DBCP case.
The requirements for logging in DBCP are such that any event listener
would end up looking very much like a logging abstraction and one of the
reasons for using C-L was to to avoid implementing yet another logging
abstraction.
Where I think an event listener approach would work is in POOL. In POOL
there is a very small, very specific logging requirement (the few places
where an exception is swallowed). Currently, this is implemented with
JMX notifications which was the least bad of the options that were
suggested at the time. However, an event listener is significantly
better than JMX. I wish I had thought of that solution before I spent
the time on JMX notifications. Doesn't stop me using the idea though :)
I'll create an JIRA to replace the JMX notifications with a
SwallowedExceptionListener or similar.
Thanks for suggesting this.
Mark
>
> On Wednesday, July 24, 2013, Phil Steitz wrote:
>
>> On 7/24/13 12:56 AM, Mark Thomas wrote:
>>> I'm working my way through the open DBCP bugs with a view to getting the
>>> DBCP code (and the POOL code as some changes may be required there) into
>>> a state where it is ready for the first v2 release.
>>>
>>> I've quickly reached DBCP-154 that requests that logging is added. This
>>> is not a new request and goes back to DBCP-4 and possibly earlier. From
>>> memory there are a number of open DBCP bugs that require some form of
>>> logging. There are also lots of places where DBCP logs directly to
>>> stdout or stderr.
>>>
>>> This quickly brings us to the point of having to decide which logging
>>> framework to use. This is largely the same debate we had for POOL [1]
>>> but with a few key differences:
>>> - there are many more places where logging is required
>>> - there are many more places where logging could be useful
>>>
>>> Because of the volume of logging, I don't believe the JMX approach used
>>> for POOL is viable for DBCP.
>>>
>>> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>>
>> First, many thanks for jumping back in!
>>
>> I have two basic questions:
>>
>> 1) Do we absolutely need logging itself or is there some other way
>> we could satisfy the needs here? IIRC, there are basically two
>> things that "require" logging in DBCP: a) abandoned connections b)
>> exceptions / warnings. In a), we want users to be able to log the
>> stack trace of the code that opened the connection. Case b) splits
>> into all kinds of different stuff. This may be a little smelly, but
>> I wonder if we could not shove what is really needed in normal
>> operations into JMX properties (which would just hold information
>> from recent messages) and support a debug mode where things get
>> spewed as today to System.err or a configured LogWriter.
>>
>> 2) Are there any real reasons that commons-logging will not meet the
>> need? I have read the other messages on this thread and have not
>> seen a concrete reason, other than "others like slf2j better." Have
>> we in fact definitively resolved the classloader-related issues that
>> used to make commons-logging a bad choice?
>>
>> If the answer to 1) is we absolutely need logging and 2) comes down
>> to a matter of taste, I am +1 on commons-logging because I agree
>> with the dogfood argument and also do-ocracy ;)
>>
>> Phil
>>>
>>> Mark
>>>
>>>
>>> [1] http://markmail.org/message/zuufedzkfx62v5eq
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>>
>>> .
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I like it!
Le 27 juil. 2013 04:24, "James Carman" <ja...@carmanconsulting.com> a
écrit :
> On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> > On Jul 26, 2013, at 19:24, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> >> Perhaps an event listener for all dbcp events? Then folks can log it
> >> themselves.
> >
> > I would then expect dbcp to deliver a logging implementation, probably
> > not hooked up by default.
> >
>
> We could do that, and have optional dependencies on the logging
> libraries (Commons Logging, SLF4J, etc.).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Jul 26, 2013, at 19:24, James Carman <ja...@carmanconsulting.com> wrote:
>
>> Perhaps an event listener for all dbcp events? Then folks can log it
>> themselves.
>
> I would then expect dbcp to deliver a logging implementation, probably
> not hooked up by default.
>
We could do that, and have optional dependencies on the logging
libraries (Commons Logging, SLF4J, etc.).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Gary Gregory <ga...@gmail.com>.
On Jul 26, 2013, at 19:24, James Carman <ja...@carmanconsulting.com> wrote:
> Perhaps an event listener for all dbcp events? Then folks can log it
> themselves.
I would then expect dbcp to deliver a logging implementation, probably
not hooked up by default.
Gary
> I would be concerned about performance unless of course the
> events are delivered asynchronously.
>
> On Wednesday, July 24, 2013, Phil Steitz wrote:
>
>> On 7/24/13 12:56 AM, Mark Thomas wrote:
>>> I'm working my way through the open DBCP bugs with a view to getting the
>>> DBCP code (and the POOL code as some changes may be required there) into
>>> a state where it is ready for the first v2 release.
>>>
>>> I've quickly reached DBCP-154 that requests that logging is added. This
>>> is not a new request and goes back to DBCP-4 and possibly earlier. From
>>> memory there are a number of open DBCP bugs that require some form of
>>> logging. There are also lots of places where DBCP logs directly to
>>> stdout or stderr.
>>>
>>> This quickly brings us to the point of having to decide which logging
>>> framework to use. This is largely the same debate we had for POOL [1]
>>> but with a few key differences:
>>> - there are many more places where logging is required
>>> - there are many more places where logging could be useful
>>>
>>> Because of the volume of logging, I don't believe the JMX approach used
>>> for POOL is viable for DBCP.
>>>
>>> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>>
>> First, many thanks for jumping back in!
>>
>> I have two basic questions:
>>
>> 1) Do we absolutely need logging itself or is there some other way
>> we could satisfy the needs here? IIRC, there are basically two
>> things that "require" logging in DBCP: a) abandoned connections b)
>> exceptions / warnings. In a), we want users to be able to log the
>> stack trace of the code that opened the connection. Case b) splits
>> into all kinds of different stuff. This may be a little smelly, but
>> I wonder if we could not shove what is really needed in normal
>> operations into JMX properties (which would just hold information
>> from recent messages) and support a debug mode where things get
>> spewed as today to System.err or a configured LogWriter.
>>
>> 2) Are there any real reasons that commons-logging will not meet the
>> need? I have read the other messages on this thread and have not
>> seen a concrete reason, other than "others like slf2j better." Have
>> we in fact definitively resolved the classloader-related issues that
>> used to make commons-logging a bad choice?
>>
>> If the answer to 1) is we absolutely need logging and 2) comes down
>> to a matter of taste, I am +1 on commons-logging because I agree
>> with the dogfood argument and also do-ocracy ;)
>>
>> Phil
>>>
>>> Mark
>>>
>>>
>>> [1] http://markmail.org/message/zuufedzkfx62v5eq
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>>
>>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by James Carman <ja...@carmanconsulting.com>.
Perhaps an event listener for all dbcp events? Then folks can log it
themselves. I would be concerned about performance unless of course the
events are delivered asynchronously.
On Wednesday, July 24, 2013, Phil Steitz wrote:
> On 7/24/13 12:56 AM, Mark Thomas wrote:
> > I'm working my way through the open DBCP bugs with a view to getting the
> > DBCP code (and the POOL code as some changes may be required there) into
> > a state where it is ready for the first v2 release.
> >
> > I've quickly reached DBCP-154 that requests that logging is added. This
> > is not a new request and goes back to DBCP-4 and possibly earlier. From
> > memory there are a number of open DBCP bugs that require some form of
> > logging. There are also lots of places where DBCP logs directly to
> > stdout or stderr.
> >
> > This quickly brings us to the point of having to decide which logging
> > framework to use. This is largely the same debate we had for POOL [1]
> > but with a few key differences:
> > - there are many more places where logging is required
> > - there are many more places where logging could be useful
> >
> > Because of the volume of logging, I don't believe the JMX approach used
> > for POOL is viable for DBCP.
> >
> > Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>
> First, many thanks for jumping back in!
>
> I have two basic questions:
>
> 1) Do we absolutely need logging itself or is there some other way
> we could satisfy the needs here? IIRC, there are basically two
> things that "require" logging in DBCP: a) abandoned connections b)
> exceptions / warnings. In a), we want users to be able to log the
> stack trace of the code that opened the connection. Case b) splits
> into all kinds of different stuff. This may be a little smelly, but
> I wonder if we could not shove what is really needed in normal
> operations into JMX properties (which would just hold information
> from recent messages) and support a debug mode where things get
> spewed as today to System.err or a configured LogWriter.
>
> 2) Are there any real reasons that commons-logging will not meet the
> need? I have read the other messages on this thread and have not
> seen a concrete reason, other than "others like slf2j better." Have
> we in fact definitively resolved the classloader-related issues that
> used to make commons-logging a bad choice?
>
> If the answer to 1) is we absolutely need logging and 2) comes down
> to a matter of taste, I am +1 on commons-logging because I agree
> with the dogfood argument and also do-ocracy ;)
>
> Phil
> >
> > Mark
> >
> >
> > [1] http://markmail.org/message/zuufedzkfx62v5eq
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> > .
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>
>
RE: [DBCP] DBCP2 and logging
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
AFAIK, some of the classloader "issues" with CL still remain (see http://xnet.wanconcepts.com/jcl/furtherAnalysis.html but also see here: http://commons.apache.org/proper/commons-logging/tech.html) So, IMO Commons projects still ought to use it, if for no other reason than to understand what the issues are in practice (vis-à-vis dog-fooding). And one of the original authors of JCL proposes that it SHOULD be used in just this situation (DBCP): http://radio-weblogs.com/0122027/2003/08/15.html
<quote>
If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging
framework they're going to want to use, then commons-logging might be useful to you.
</quote>
~Roger Whitcomb
-----Original Message-----
From: Phil Steitz [mailto:phil.steitz@gmail.com]
Sent: Wednesday, July 24, 2013 9:15 AM
To: Commons Developers List
Subject: Re: [DBCP] DBCP2 and logging
On 7/24/13 12:56 AM, Mark Thomas wrote:
> I'm working my way through the open DBCP bugs with a view to getting
> the DBCP code (and the POOL code as some changes may be required
> there) into a state where it is ready for the first v2 release.
>
> I've quickly reached DBCP-154 that requests that logging is added.
> This is not a new request and goes back to DBCP-4 and possibly
> earlier. From memory there are a number of open DBCP bugs that require
> some form of logging. There are also lots of places where DBCP logs
> directly to stdout or stderr.
>
> This quickly brings us to the point of having to decide which logging
> framework to use. This is largely the same debate we had for POOL [1]
> but with a few key differences:
> - there are many more places where logging is required
> - there are many more places where logging could be useful
>
> Because of the volume of logging, I don't believe the JMX approach
> used for POOL is viable for DBCP.
>
> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
First, many thanks for jumping back in!
I have two basic questions:
1) Do we absolutely need logging itself or is there some other way we could satisfy the needs here? IIRC, there are basically two things that "require" logging in DBCP: a) abandoned connections b) exceptions / warnings. In a), we want users to be able to log the stack trace of the code that opened the connection. Case b) splits into all kinds of different stuff. This may be a little smelly, but I wonder if we could not shove what is really needed in normal operations into JMX properties (which would just hold information from recent messages) and support a debug mode where things get spewed as today to System.err or a configured LogWriter.
2) Are there any real reasons that commons-logging will not meet the need? I have read the other messages on this thread and have not seen a concrete reason, other than "others like slf2j better." Have we in fact definitively resolved the classloader-related issues that used to make commons-logging a bad choice?
If the answer to 1) is we absolutely need logging and 2) comes down to a matter of taste, I am +1 on commons-logging because I agree with the dogfood argument and also do-ocracy ;)
Phil
>
> Mark
>
>
> [1] http://markmail.org/message/zuufedzkfx62v5eq
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Phil Steitz <ph...@gmail.com>.
On 7/24/13 12:56 AM, Mark Thomas wrote:
> I'm working my way through the open DBCP bugs with a view to getting the
> DBCP code (and the POOL code as some changes may be required there) into
> a state where it is ready for the first v2 release.
>
> I've quickly reached DBCP-154 that requests that logging is added. This
> is not a new request and goes back to DBCP-4 and possibly earlier. From
> memory there are a number of open DBCP bugs that require some form of
> logging. There are also lots of places where DBCP logs directly to
> stdout or stderr.
>
> This quickly brings us to the point of having to decide which logging
> framework to use. This is largely the same debate we had for POOL [1]
> but with a few key differences:
> - there are many more places where logging is required
> - there are many more places where logging could be useful
>
> Because of the volume of logging, I don't believe the JMX approach used
> for POOL is viable for DBCP.
>
> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
First, many thanks for jumping back in!
I have two basic questions:
1) Do we absolutely need logging itself or is there some other way
we could satisfy the needs here? IIRC, there are basically two
things that "require" logging in DBCP: a) abandoned connections b)
exceptions / warnings. In a), we want users to be able to log the
stack trace of the code that opened the connection. Case b) splits
into all kinds of different stuff. This may be a little smelly, but
I wonder if we could not shove what is really needed in normal
operations into JMX properties (which would just hold information
from recent messages) and support a debug mode where things get
spewed as today to System.err or a configured LogWriter.
2) Are there any real reasons that commons-logging will not meet the
need? I have read the other messages on this thread and have not
seen a concrete reason, other than "others like slf2j better." Have
we in fact definitively resolved the classloader-related issues that
used to make commons-logging a bad choice?
If the answer to 1) is we absolutely need logging and 2) comes down
to a matter of taste, I am +1 on commons-logging because I agree
with the dogfood argument and also do-ocracy ;)
Phil
>
> Mark
>
>
> [1] http://markmail.org/message/zuufedzkfx62v5eq
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i didn't propose to reloacte here but just to take into account classloader
issues.
JULI (tomcat) is not that bad in practise and will lead to less conflicting
issues IMO. Do you think to other cases saying JUL is not adapted?
My point about JDBC 4 features is we'll use JUL in all cases when upgrading
so why not aligning on it right now.
About eating our own food: it was consistent while there were no commonly
used facade. It seems today apache frameworks like slf4j more than CL (at
least the one i use commonly) so maybe time to change.
To summarize my opinion: if you use slf4j i'll not fight but i think JUL is
far enough for this case.
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas <ma...@apache.org>
> On 24/07/2013 11:44, Romain Manni-Bucau wrote:
> > well what i don't get is you (understand as tomcat guy) are the first to
> > relocate classes to avoid clashes with apps and here you don't want.
>
> Relocating classes here won't help. If a container and an app both try
> to use a version of DBCP that uses a relocated Commons Logging both DBCP
> and the relocated Commons Logging will clash.
>
> If relocation the preferred use case then the container has to relocate
> DBCP and Logging. Relocating things in the library doesn't help.
>
> > we worked on tomee to limit the side effects but we can't guarantee it at
> > 100% (typically one weird case is
> > https://issues.apache.org/jira/browse/TOMEE-758)
>
> From the description it looks like relocation would fix that issue
> although logging is usually sufficiently complex that there may well be
> additional factors that mean relocation isn't a viable option.
>
> > I think i have 2 points for JUL:
> >
> > 1) logging is mainly for exceptions so no need to bring something for a
> > case which shouldn't be that common
> >
> > 2) DBCP is highly linked to JDBC and JDBC uses JUL in its recent API
> (java
> > 7 IIRC) so maybe we should just align on it
>
> DBCP currently throws SQLFeatureNotSupportedException in all cases for
> the one JDBC 4.1 method that uses JUL. I do not propose changing that.
>
> Reasons not to use JUL for DBCP:
> - JUL is fundamentally broken in a container environment as it is not
> class loader aware.
> - The JUL to SLF4J bridge has performance issues.
> - Other frameworks that seek to replace JUL would have the same
> performance issues. JUL is a very poor choice for a facade.
>
> There are options for the logging facade. Commons Logging is one. SLF4J
> is another. There are others but JUL is not one of them. Primarily from
> an eating your own dog food PoV, Commons Logging is the option I'm
> working with for DBCP.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/2013 11:44, Romain Manni-Bucau wrote:
> well what i don't get is you (understand as tomcat guy) are the first to
> relocate classes to avoid clashes with apps and here you don't want.
Relocating classes here won't help. If a container and an app both try
to use a version of DBCP that uses a relocated Commons Logging both DBCP
and the relocated Commons Logging will clash.
If relocation the preferred use case then the container has to relocate
DBCP and Logging. Relocating things in the library doesn't help.
> we worked on tomee to limit the side effects but we can't guarantee it at
> 100% (typically one weird case is
> https://issues.apache.org/jira/browse/TOMEE-758)
>From the description it looks like relocation would fix that issue
although logging is usually sufficiently complex that there may well be
additional factors that mean relocation isn't a viable option.
> I think i have 2 points for JUL:
>
> 1) logging is mainly for exceptions so no need to bring something for a
> case which shouldn't be that common
>
> 2) DBCP is highly linked to JDBC and JDBC uses JUL in its recent API (java
> 7 IIRC) so maybe we should just align on it
DBCP currently throws SQLFeatureNotSupportedException in all cases for
the one JDBC 4.1 method that uses JUL. I do not propose changing that.
Reasons not to use JUL for DBCP:
- JUL is fundamentally broken in a container environment as it is not
class loader aware.
- The JUL to SLF4J bridge has performance issues.
- Other frameworks that seek to replace JUL would have the same
performance issues. JUL is a very poor choice for a facade.
There are options for the logging facade. Commons Logging is one. SLF4J
is another. There are others but JUL is not one of them. Primarily from
an eating your own dog food PoV, Commons Logging is the option I'm
working with for DBCP.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well what i don't get is you (understand as tomcat guy) are the first to
relocate classes to avoid clashes with apps and here you don't want.
we worked on tomee to limit the side effects but we can't guarantee it at
100% (typically one weird case is
https://issues.apache.org/jira/browse/TOMEE-758)
I think i have 2 points for JUL:
1) logging is mainly for exceptions so no need to bring something for a
case which shouldn't be that common
2) DBCP is highly linked to JDBC and JDBC uses JUL in its recent API (java
7 IIRC) so maybe we should just align on it
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas <ma...@apache.org>
> On 24/07/2013 10:38, Romain Manni-Bucau wrote:
> > that's one issue we have we tomee, some deps use CL.
>
> So it is a problem you have already solved.
>
> > Moreover CL has issue in classloader trees for years so i don't think
> > that's a good choice at all.
>
> Then we have different views.
>
> > slf4j is clearly better supported and is light too.
>
> If slf4j is your logging framework of choice then simply don't use
> Commons Logging at all and use JCL over SLF4J.
>
> > If you don't want to redo a facade ("want" is not an answer btw) maybe
> > just reuse slf4j.
>
> I don't want to write yet another facade because there is simply no
> need. Writing another facade would make switching logging frameworks
> harder, not easier.
>
>
> There is a choice with respect to which facade DBCP uses. I'm of the
> view that we should be eating our own dog food here and if using Commons
> Logging for DBCP identifies some issues with Commons Logging then we
> should fix those issues in Commons Logging.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/2013 10:38, Romain Manni-Bucau wrote:
> that's one issue we have we tomee, some deps use CL.
So it is a problem you have already solved.
> Moreover CL has issue in classloader trees for years so i don't think
> that's a good choice at all.
Then we have different views.
> slf4j is clearly better supported and is light too.
If slf4j is your logging framework of choice then simply don't use
Commons Logging at all and use JCL over SLF4J.
> If you don't want to redo a facade ("want" is not an answer btw) maybe
> just reuse slf4j.
I don't want to write yet another facade because there is simply no
need. Writing another facade would make switching logging frameworks
harder, not easier.
There is a choice with respect to which facade DBCP uses. I'm of the
view that we should be eating our own dog food here and if using Commons
Logging for DBCP identifies some issues with Commons Logging then we
should fix those issues in Commons Logging.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
that's one issue we have we tomee, some deps use CL.
Moreover CL has issue in classloader trees for years so i don't think
that's a good choice at all. slf4j is clearly better supported and is light
too. If you don't want to redo a facade ("want" is not an answer btw) maybe
just reuse slf4j.
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas <ma...@apache.org>
> On 24/07/2013 10:02, Romain Manni-Bucau wrote:
> > you forget providing CL in container will break app usage...which justify
> > the 100 lines of code IMHO
>
> Commons Logging is safe for applications to use in a container
> environment unless the container itself is using Commons Logging
> directly in which case I'd argue that the container has a bug that needs
> to be fixed.
>
> If a container wants to provide DBCP then it is going to have to do
> something to protect against conflicts when applications use (a
> potentially different) version of DBCP. Whatever mechanism the container
> opts for can be used for Commons-Logging as well and the container can
> then plug the output of Commons-Logging into its own logging framework.
>
> There are a variety of ways to do this for Commons Logging (for example
> JCL over SLF4J) and I would argue it is better for DBCP to use
> Commons-Logging for which there is more likely to be a solution
> available for a user's logging framework of choice rather than DBCP
> inventing yet another facade.
>
> Mark
>
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/24 Mark Thomas <ma...@apache.org>
> >
> >> On 24/07/2013 09:36, Romain Manni-Bucau wrote:
> >>> Hi,
> >>>
> >>> in a bunch of "JavaEE" projects (openejb/tomee, OWB, CXF) we have a
> >> facade
> >>> in front of the logging to be able to select the framework to use. I
> know
> >>> CL is already a facade but it has the drawback to force a dependency.
> >> Maybe
> >>> it could be a more adapted approach
> >>
> >> Writing yet another logging facade to remove a 62KB dependency isn't an
> >> itch I want to scratch.
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/2013 10:02, Romain Manni-Bucau wrote:
> you forget providing CL in container will break app usage...which justify
> the 100 lines of code IMHO
Commons Logging is safe for applications to use in a container
environment unless the container itself is using Commons Logging
directly in which case I'd argue that the container has a bug that needs
to be fixed.
If a container wants to provide DBCP then it is going to have to do
something to protect against conflicts when applications use (a
potentially different) version of DBCP. Whatever mechanism the container
opts for can be used for Commons-Logging as well and the container can
then plug the output of Commons-Logging into its own logging framework.
There are a variety of ways to do this for Commons Logging (for example
JCL over SLF4J) and I would argue it is better for DBCP to use
Commons-Logging for which there is more likely to be a solution
available for a user's logging framework of choice rather than DBCP
inventing yet another facade.
Mark
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/24 Mark Thomas <ma...@apache.org>
>
>> On 24/07/2013 09:36, Romain Manni-Bucau wrote:
>>> Hi,
>>>
>>> in a bunch of "JavaEE" projects (openejb/tomee, OWB, CXF) we have a
>> facade
>>> in front of the logging to be able to select the framework to use. I know
>>> CL is already a facade but it has the drawback to force a dependency.
>> Maybe
>>> it could be a more adapted approach
>>
>> Writing yet another logging facade to remove a 62KB dependency isn't an
>> itch I want to scratch.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
you forget providing CL in container will break app usage...which justify
the 100 lines of code IMHO
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas <ma...@apache.org>
> On 24/07/2013 09:36, Romain Manni-Bucau wrote:
> > Hi,
> >
> > in a bunch of "JavaEE" projects (openejb/tomee, OWB, CXF) we have a
> facade
> > in front of the logging to be able to select the framework to use. I know
> > CL is already a facade but it has the drawback to force a dependency.
> Maybe
> > it could be a more adapted approach
>
> Writing yet another logging facade to remove a 62KB dependency isn't an
> itch I want to scratch.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBCP] DBCP2 and logging
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/2013 09:36, Romain Manni-Bucau wrote:
> Hi,
>
> in a bunch of "JavaEE" projects (openejb/tomee, OWB, CXF) we have a facade
> in front of the logging to be able to select the framework to use. I know
> CL is already a facade but it has the drawback to force a dependency. Maybe
> it could be a more adapted approach
Writing yet another logging facade to remove a 62KB dependency isn't an
itch I want to scratch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] DBCP2 and logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
in a bunch of "JavaEE" projects (openejb/tomee, OWB, CXF) we have a facade
in front of the logging to be able to select the framework to use. I know
CL is already a facade but it has the drawback to force a dependency. Maybe
it could be a more adapted approach
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas <ma...@apache.org>
> I'm working my way through the open DBCP bugs with a view to getting the
> DBCP code (and the POOL code as some changes may be required there) into
> a state where it is ready for the first v2 release.
>
> I've quickly reached DBCP-154 that requests that logging is added. This
> is not a new request and goes back to DBCP-4 and possibly earlier. From
> memory there are a number of open DBCP bugs that require some form of
> logging. There are also lots of places where DBCP logs directly to
> stdout or stderr.
>
> This quickly brings us to the point of having to decide which logging
> framework to use. This is largely the same debate we had for POOL [1]
> but with a few key differences:
> - there are many more places where logging is required
> - there are many more places where logging could be useful
>
> Because of the volume of logging, I don't believe the JMX approach used
> for POOL is viable for DBCP.
>
> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>
> Mark
>
>
> [1] http://markmail.org/message/zuufedzkfx62v5eq
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>