commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Usage of logging API in common-pool ?
Date Sat, 19 Jul 2014 22:35:48 GMT
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 (
> 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.


> Regards,
> Anthony Communier

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message