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" <garydgreg...@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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
