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