Hey guys, As Gary, I did also some AOP tricks to gather information from POOL and DBCP. It works fine, but agree that some more configurable logging would help.
In regards to the right logging implementation or the right facade to use, I'd say, none. Why not just using JUL? It comes from the JDK so no additional lib, as I fully understand Phil's point (in Apache TomEE for instance). In latest JDK versions (5 and following), it proved to be a good choice and in many projects I'm involved to, we have been using only JUL. No facade because each one think it's the best until the next one comes out ;-) No impl, cause obviously it's never the one user wants. There are some bridge between JUL and the most well known impl, so that's why I think it's a good balance. Hope it helps. Jean-Louis 2014-07-20 17:06 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > On 7/20/14, 7:54 AM, Phil Steitz wrote: > > On 7/19/14, 5:45 PM, Gary Gregory wrote: > >> I just had a case today actually, where I had to unroll > PoolUtils.prefill > >> and add logging before each call to addObject(). > > Why? > > > > Nine times out of ten, when you think you need logging when using > > [pool], you can get what you need by instrumenting *your* factory. > > In pool2, you also have all of the lifecycle stuff in the > > PooledObjects and the JMX instrumentation. > > > >> Quite a shame to be forced > >> to do that because pool does not log. In the end, this helped me debug > my > >> problem but now, I'm leave the code unrolled of course. IMO, pool is a > >> mid-level component that should log; and do so with Log4j 2. > > If [pool] is midlevel, what exactly is low-level? Pool is depended > > on by lots of projects for a pretty simple, low-level function and > > it has no dependencies itself. Performance and lightweight > > deployment are important. In 2.0, we have added good JMX > > instrumentation and I think with the right listeners, we should be > > able to handle everything but the few internal corner cases like > > OOMEs that write to System.err in the current code. Adding a > > logging dependency just for these seems a shame to me. If we > > decide we have to add something, it should be commons-logging, for > > consistency with [dbcp] and for the same reasons that choice was > > made [1]. I would really like to avoid it, if possible, though. > > > > [1] http://markmail.org/images/permalink.gif > > Oops! should be > [1] http://markmail.org/message/j2vmk4uidb3uuv6k > > > > Phil > >> Gary > >> > >> > >> On Sat, Jul 19, 2014 at 6:35 PM, Phil Steitz <phil.ste...@gmail.com> > wrote: > >> > >>> On 7/18/14, 2:18 PM, Anthony Communier wrote: > >>>> Hello, > >>>> > >>>> There are some parts of the code that use printStackTrace in order to > >>> show > >>>> errors. It means that it's difficult to have control on how log will > be > >>>> produced. Those stacks will mainly go to application server logs and > not > >>>> directly into application logs if an application server is used (like > >>>> tomcat, Jboss, ..). That's why I suggest to use logging API, like > other > >>>> libraries > >>>> > >>>> I have posted an issue in Jira POOL-266 ( > >>>> https://issues.apache.org/jira/browse/POOL-266). Phil Steitz added a > >>>> comment on the issue (Today 21:1) > >>>> > >>>> "The reason that we don't use a logging API is to avoid introducing a > >>>> dependency. If we do go that route, we should be consistent with DBCP > and > >>>> use commons-logging. I am not sure we really want to go this way, > >>> though. I > >>>> am more inclined to support the suggestion in POOL-267. It would be > >>> better > >>>> to discuss these things on the commons dev mailing list." > >>> Unfortunately, the POOL-267 approach works only for the abandoned > >>> instance tracking part. I had forgotten that we have in fact added > >>> some printStackTraces for errors (sort of extreme cases, but > >>> still...) in 2.x. We need a solution for these as well. See [1] > >>> for previous discussion of this topic. > >>> > >>> Now that we cut 2.x releases, we obviously have to think about > >>> compatibility. I think the listeners stuff should be able to be > >>> done compatibly; but adding a dependency is probably not something > >>> we want to do in a dot release. > >>> > >>> What would be great would be a way to add listeners / configuration > >>> options that would make it possible for users to pipe trace info to > >>> whatever persistence mechanisms they want. We have talked about > >>> this in the past, but never settled on an approach. Again, see > >>> [1]. I tend to agree with the sentiment that a low-level component > >>> like [pool] should emit very little, ideally nothing, in terms of > >>> logging, but provide good access to the information needed by > >>> components up the stack to handle and report errors and gather > >>> diagnostic information. > >>> > >>> Phil > >>> > >>> [1] http://markmail.org/message/zuufedzkfx62v5eq > >>>> Regards, > >>>> > >>>> Anthony Communier > >>>> > >>> --------------------------------------------------------------------- > >>> 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 > > -- Jean-Louis
