[pool] Usage of logging API in common-pool ?

[Anthony Communier <an...@gmail.com>]

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


Regards,

Anthony Communier

Re: [pool] Usage of logging API in common-pool ?

[Jean-Louis MONTEIRO <je...@gmail.com>]

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 <ph...@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 <ph...@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Jean-Louis

Re: [pool] Usage of logging API in common-pool ?

[Phil Steitz <ph...@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 <ph...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [pool] Usage of logging API in common-pool ?

[Phil Steitz <ph...@gmail.com>]

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 <ph...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [pool] Usage of logging API in common-pool ?

[Gary Gregory <ga...@gmail.com>]

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 <ph...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Re: [pool] Usage of logging API in common-pool ?

[Phil Steitz <ph...@gmail.com>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org