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
