Re: [DBCP] DBCP2 and logging

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 re

Re: [DBCP] DBCP2 and logging

I like it! Le 27 juil. 2013 04:24, "James Carman" a écrit : > On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory > wrote: > > On Jul 26, 2013, at 19:24, James Carman > wrote: > > > >> Perhaps an event listener for all dbcp events? Then folks can log it > >> themselves. > > > > I would then expect

Re: [DBCP] DBCP2 and logging

On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory wrote: > On Jul 26, 2013, at 19:24, James Carman 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. >

Re: [DBCP] DBCP2 and logging

On Jul 26, 2013, at 19:24, James Carman 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

Re: [DBCP] DBCP2 and logging

On Jul 26, 2013, at 8:22 PM, sebb 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

Re: [DBCP] DBCP2 and logging

On 27 July 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. So long as the docs make very clear that the listener must complete

Re: [DBCP] DBCP2 and logging

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 thro

Re: [DBCP] DBCP2 and logging

for sure since it bothers a bunch of people, doing a superb library which is not usable is useless *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rm

Re: [DBCP] DBCP2 and logging

2013/7/24 Romain Manni-Bucau > 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

Re: [DBCP] DBCP2 and logging

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" a écrit : > Le 24/07/2013 18:53, Romain Manni-Bucau a écrit : > > > about "slf4j is better supported": since it is more

Re: [DBCP] DBCP2 and logging

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 signature.

Re: [DBCP] DBCP2 and logging

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" a écrit : > Also, for JCL we can fix things nice and quick. > > Gary > > On Jul 24, 2013, at 13:29, Mark Thomas wrote: > > >

Re: [DBCP] DBCP2 and logging

Also, for JCL we can fix things nice and quick. Gary On Jul 24, 2013, at 13:29, Mark Thomas 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

Re: [DBCP] DBCP2 and logging

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 a

Re: [DBCP] DBCP2 and logging

@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 s

Re: [DBCP] DBCP2 and logging

On Wed, Jul 24, 2013 at 12:36 PM, Romain Manni-Bucau 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

Re: [DBCP] DBCP2 and logging

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

RE: [DBCP] DBCP2 and logging

o you. ~Roger Whitcomb -Original Message- From: Phil Steitz [mailto:phil.ste...@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 b

Re: [DBCP] DBCP2 and logging

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 * *Blog: **ht

Re: [DBCP] DBCP2 and logging

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 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

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 lo

Re: [DBCP] DBCP2 and logging

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 upgr

Re: [DBCP] DBCP2 and logging

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

Re: [DBCP] DBCP2 and logging

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)

Re: [DBCP] DBCP2 and logging

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 clear

Re: [DBCP] DBCP2 and logging

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. *Rom

Re: [DBCP] DBCP2 and logging

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

Re: [DBCP] DBCP2 and logging

you forget providing CL in container will break app usage...which justify the 100 lines of code IMHO *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/

Re: [DBCP] DBCP2 and logging

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 b

Re: [DBCP] DBCP2 and logging

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: @

[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 goe