I just had a case today actually, where I had to unroll PoolUtils.prefill and add logging before each call to addObject(). 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.
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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
