You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2012/02/09 23:25:42 UTC
[DISCUSS][POOL] Logging options for Pool2
One of the big design decisions left for pool2 is whether or not to add
logging. If logging is added then that opens up the what to log and with
which logging framework questions.
I do think some form of logging is required.
See POOL-131 for one example of where logging could be useful.
I have a preference for commons-logging. Partly since it is eating our
own dog food, partly because it will make updating Tomcat to use pool2
easier.
I did have a random thought that we could do zero logging but emit JMX
notifications if JMX was enabled. It avoids the "which framework" debate
but uses an approach that is far less widely used in my experience.
All this is because I am (hopefully) getting close to the point where
the pool2 code is ready for an alpha release.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Mark Thomas <ma...@apache.org>.
On 17/02/2012 21:13, Gary Gregory wrote:
> So... are we ready to move some bits?
> ;)
Getting there. I had some Tomcat stuff to do. I'll try and look at this
this week.
Mark
> Gary
>
> On Sun, Feb 12, 2012 at 8:03 PM, Konstantin Kolinko
> <kn...@gmail.com>wrote:
>
>> 2012/2/13 Mark Thomas <ma...@apache.org>:
>>>
>>> General
>>> - Logging in pool, if any, should be minimal
>>>
>>
>> Two general questions:
>> When there are several pools,
>> - is it possible to discern log messages from different pools?
>> - is it possible to control logging level for a single pool, or all
>> pools have the same logging configuration? E.g. to enable debug
>> logging for a single pool only (if debug logging is ever implemented
>> there).
>>
>>>
>>> What do folks think to the following solution:
>>> - make logging of factory exceptions a factory responsibility - clearly
>>> documented in the JavaDoc for POOL2
>>> - add some JMX stats to POOL2 for number of destroy / passivate /
>>> activate exceptions
>>> - make the last n (10?) exceptions of each type accessible via JMX for
>> POOL2
>>> ?
>>>
>>
>> Overall this proposal looks good, but there is known caveat with
>> keeping Exception instances in memory: Their stacktrace data is known
>> to pin classloaders in memory, preventing them from being garbage
>> collected and thus causing PermGen memory leaks in web applications.
>>
>> This problem was reproduced in this Tomcat issue:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50460
>> Discussion:
>> http://marc.info/?l=tomcat-dev&m=129211856426188&w=2
>>
>> A workaround might be to print stacktraces as strings and keep the
>> strings in memory, but it may be time-consuming. The good point though
>> is that the time to print those exceptions to strings is comparable
>> with the one spent when printing them to a log file.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>> 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: [DISCUSS][POOL] Logging options for Pool2
Posted by Gary Gregory <ga...@gmail.com>.
So... are we ready to move some bits?
;)
Gary
On Sun, Feb 12, 2012 at 8:03 PM, Konstantin Kolinko
<kn...@gmail.com>wrote:
> 2012/2/13 Mark Thomas <ma...@apache.org>:
> >
> > General
> > - Logging in pool, if any, should be minimal
> >
>
> Two general questions:
> When there are several pools,
> - is it possible to discern log messages from different pools?
> - is it possible to control logging level for a single pool, or all
> pools have the same logging configuration? E.g. to enable debug
> logging for a single pool only (if debug logging is ever implemented
> there).
>
> >
> > What do folks think to the following solution:
> > - make logging of factory exceptions a factory responsibility - clearly
> > documented in the JavaDoc for POOL2
> > - add some JMX stats to POOL2 for number of destroy / passivate /
> > activate exceptions
> > - make the last n (10?) exceptions of each type accessible via JMX for
> POOL2
> > ?
> >
>
> Overall this proposal looks good, but there is known caveat with
> keeping Exception instances in memory: Their stacktrace data is known
> to pin classloaders in memory, preventing them from being garbage
> collected and thus causing PermGen memory leaks in web applications.
>
> This problem was reproduced in this Tomcat issue:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50460
> Discussion:
> http://marc.info/?l=tomcat-dev&m=129211856426188&w=2
>
> A workaround might be to print stacktraces as strings and keep the
> strings in memory, but it may be time-consuming. The good point though
> is that the time to print those exceptions to strings is comparable
> with the one spent when printing them to a log file.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> 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
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/13 Mark Thomas <ma...@apache.org>:
>
> General
> - Logging in pool, if any, should be minimal
>
Two general questions:
When there are several pools,
- is it possible to discern log messages from different pools?
- is it possible to control logging level for a single pool, or all
pools have the same logging configuration? E.g. to enable debug
logging for a single pool only (if debug logging is ever implemented
there).
>
> What do folks think to the following solution:
> - make logging of factory exceptions a factory responsibility - clearly
> documented in the JavaDoc for POOL2
> - add some JMX stats to POOL2 for number of destroy / passivate /
> activate exceptions
> - make the last n (10?) exceptions of each type accessible via JMX for POOL2
> ?
>
Overall this proposal looks good, but there is known caveat with
keeping Exception instances in memory: Their stacktrace data is known
to pin classloaders in memory, preventing them from being garbage
collected and thus causing PermGen memory leaks in web applications.
This problem was reproduced in this Tomcat issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50460
Discussion:
http://marc.info/?l=tomcat-dev&m=129211856426188&w=2
A workaround might be to print stacktraces as strings and keep the
strings in memory, but it may be time-consuming. The good point though
is that the time to print those exceptions to strings is comparable
with the one spent when printing them to a log file.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Mark Thomas <ma...@apache.org>.
Thanks to all who contributed to this thread. I thought it might be
useful to summarize the discussion so far.
Preferences have been expressed for:
- java.util.logging (jul)
- commons logging (cl)
- SLF4J
General
- Logging in pool, if any, should be minimal
jul
- Anything other than jul adds a new dependency
- not a good choice for JavaEE environments
- very inefficient to bridge to something else
cl
- has a minimal API
- fine for JavaEE
slf4j
- fine for JavaEE
Revisiting the issue (POOL-131) that triggered this, an argument could
be made that this is a DBCP problem rather than a POOL one since DBCP is
throwing a factory exception and not logging it. See POOL-142 for why
this is a factory problem. However, all that does is move the same
problem to DBCP.
What do folks think to the following solution:
- make logging of factory exceptions a factory responsibility - clearly
documented in the JavaDoc for POOL2
- add some JMX stats to POOL2 for number of destroy / passivate /
activate exceptions
- make the last n (10?) exceptions of each type accessible via JMX for POOL2
?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Bill Barker <bi...@verizon.net>.
I'm not involved with [POOL] (so this is mostly from the peanut gallery),
but do strongly think that logging should be minimal for such a low level
component. As such, if there needs to be any logging at all, it should use
JUL. While it would be nice in a development environment so see my bone
headed errors (where I have full control over logging levels with JULI that
I currently use in Tomcat), I want [POOL] to be completely silent in a
production environment. So it should be a lot of work to configure logging
for [POOL] to be higher than DEBUG/TRACE level in a production environment,
since you already screwed up by releasing the code in the first place.
-----Original Message-----
From: Mark Thomas
Sent: Thursday, February 09, 2012 2:25 PM
To: Commons Developers List
Subject: [DISCUSS][POOL] Logging options for Pool2
One of the big design decisions left for pool2 is whether or not to add
logging. If logging is added then that opens up the what to log and with
which logging framework questions.
I do think some form of logging is required.
See POOL-131 for one example of where logging could be useful.
I have a preference for commons-logging. Partly since it is eating our
own dog food, partly because it will make updating Tomcat to use pool2
easier.
I did have a random thought that we could do zero logging but emit JMX
notifications if JMX was enabled. It avoids the "which framework" debate
but uses an approach that is far less widely used in my experience.
All this is because I am (hopefully) getting close to the point where
the pool2 code is ready for an alpha release.
Thoughts?
Mark
---------------------------------------------------------------------
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: [DISCUSS][POOL] Logging options for Pool2
Posted by Simone Tripodi <si...@apache.org>.
Hi Gary,
apologize, I meant the native java.util.logging.* APIs.
all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Feb 10, 2012 at 1:16 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
>
>> On 10/02/2012 00:20, Simone Tripodi wrote:
>>> I have a preference fo juli.
>> I can work with that.
>
> Is a dependency on JULI better than on common-logging?
>
> Or is there some confusion talking about JUL vs JULI?
>
> Gary
>>
>>> IIRC, Tomcat has a bridge from juli to logging impl,
>> It is actually the other way around. Tomcat uses a package renamed
>> commons-logging hard-coded to output to juli by default. It provides a
>> package renamed full commons-logging impl as well for users that want to
>> use something else (usually log4j).
>>
>>> it would help to keep [pool] dependencies-less.
>> That is a very big advantage of juli.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Simone Tripodi <si...@apache.org>.
Hi Ralph,
log4j2 looks really promising, I'll join the logging ML.
And nice to see fluido-skin in action :P
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Feb 10, 2012 at 9:34 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> The better thing to do would be to point you to http://logback.qos.ch or http://people.apache.org/~rgoers/log4j2/. Compare the features in either of those against JUL.
>
> When building a framework you can't look at logging in isolation. Nobody wants to configure JUL and Logback and Log4j, etc.
>
> Ralph
>
> On Feb 10, 2012, at 12:14 PM, Simone Tripodi wrote:
>
>> Hi Ralph,
>>
>> just for a matter of curiosity and filling my lacks of knowledge, can
>> you point me please to some doc about the lacks of j.u.l. ?
>>
>> Many thanks in advance, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Feb 10, 2012 at 9:07 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>>>
>>>>>
>>>>
>>>> Yeah, that isn't going to work. I really do wish java.util.logging had
>>>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
>>>> this in Tomcat but even with JULI the APIs just aren't available to do
>>>> this. You could do JVM specific hacks but they will break just as soon
>>>> as the JVM vendor changes their internal API (as they are perfectly
>>>> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
>>>
>>> Sorry, JUL wasn't designed with anything in mind as far as I can tell. It sucks as a facade and the implementation is barely adequate. I've delayed creating the bridge from JUL to Log4j 2 primarily because all the ways to do it are bad.
>>>
>>>>
>>>> With this in mind, commons-logging is a better choice as it should be
>>>> possible to have an entirely contained logging setup within the
>>>> application and a properly written container shouldn't interfere with
>>>> this. Commons-logging is also relatively simple to redirect to something
>>>> else.
>>>
>>> That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
>>>>
>>>> Given the discussion so far has been around commons-logging or
>>>> java.util.logging, I think these two are the front runners. I can live
>>>> with either but I have a very narrow focus - i.e. what can i get working
>>>> easily with Tomcat's packaged renamed version of pool2.
>>>
>>> I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty well.
>>>
>>>>
>>>> Taking a wider view, commons-logging is probably the better choice as
>>>> although it adds a dependency, it is easier for folks to integrate with
>>>> their logging framework of choice.
>>>>
>>>
>>> Yes, it is a much better choice than JUL just because of that.
>>>
>>> Ralph
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Ralph Goers <ra...@dslextreme.com>.
The better thing to do would be to point you to http://logback.qos.ch or http://people.apache.org/~rgoers/log4j2/. Compare the features in either of those against JUL.
When building a framework you can't look at logging in isolation. Nobody wants to configure JUL and Logback and Log4j, etc.
Ralph
On Feb 10, 2012, at 12:14 PM, Simone Tripodi wrote:
> Hi Ralph,
>
> just for a matter of curiosity and filling my lacks of knowledge, can
> you point me please to some doc about the lacks of j.u.l. ?
>
> Many thanks in advance, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Feb 10, 2012 at 9:07 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>>
>>>>
>>>
>>> Yeah, that isn't going to work. I really do wish java.util.logging had
>>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
>>> this in Tomcat but even with JULI the APIs just aren't available to do
>>> this. You could do JVM specific hacks but they will break just as soon
>>> as the JVM vendor changes their internal API (as they are perfectly
>>> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
>>
>> Sorry, JUL wasn't designed with anything in mind as far as I can tell. It sucks as a facade and the implementation is barely adequate. I've delayed creating the bridge from JUL to Log4j 2 primarily because all the ways to do it are bad.
>>
>>>
>>> With this in mind, commons-logging is a better choice as it should be
>>> possible to have an entirely contained logging setup within the
>>> application and a properly written container shouldn't interfere with
>>> this. Commons-logging is also relatively simple to redirect to something
>>> else.
>>
>> That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
>>>
>>> Given the discussion so far has been around commons-logging or
>>> java.util.logging, I think these two are the front runners. I can live
>>> with either but I have a very narrow focus - i.e. what can i get working
>>> easily with Tomcat's packaged renamed version of pool2.
>>
>> I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty well.
>>
>>>
>>> Taking a wider view, commons-logging is probably the better choice as
>>> although it adds a dependency, it is easier for folks to integrate with
>>> their logging framework of choice.
>>>
>>
>> Yes, it is a much better choice than JUL just because of that.
>>
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> 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: [DISCUSS][POOL] Logging options for Pool2
Posted by Simone Tripodi <si...@apache.org>.
Hi Ralph,
just for a matter of curiosity and filling my lacks of knowledge, can
you point me please to some doc about the lacks of j.u.l. ?
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Feb 10, 2012 at 9:07 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>
>>>
>>
>> Yeah, that isn't going to work. I really do wish java.util.logging had
>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
>> this in Tomcat but even with JULI the APIs just aren't available to do
>> this. You could do JVM specific hacks but they will break just as soon
>> as the JVM vendor changes their internal API (as they are perfectly
>> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
>
> Sorry, JUL wasn't designed with anything in mind as far as I can tell. It sucks as a facade and the implementation is barely adequate. I've delayed creating the bridge from JUL to Log4j 2 primarily because all the ways to do it are bad.
>
>>
>> With this in mind, commons-logging is a better choice as it should be
>> possible to have an entirely contained logging setup within the
>> application and a properly written container shouldn't interfere with
>> this. Commons-logging is also relatively simple to redirect to something
>> else.
>
> That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
>>
>> Given the discussion so far has been around commons-logging or
>> java.util.logging, I think these two are the front runners. I can live
>> with either but I have a very narrow focus - i.e. what can i get working
>> easily with Tomcat's packaged renamed version of pool2.
>
> I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty well.
>
>>
>> Taking a wider view, commons-logging is probably the better choice as
>> although it adds a dependency, it is easier for folks to integrate with
>> their logging framework of choice.
>>
>
> Yes, it is a much better choice than JUL just because of that.
>
> Ralph
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS][POOL] Logging options for Pool2
Posted by Gary Gregory <ga...@gmail.com>.
On Feb 10, 2012, at 15:08, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>
>>>
>>
>> Yeah, that isn't going to work. I really do wish java.util.logging had
>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
>> this in Tomcat but even with JULI the APIs just aren't available to do
>> this. You could do JVM specific hacks but they will break just as soon
>> as the JVM vendor changes their internal API (as they are perfectly
>> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
>
> Sorry, JUL wasn't designed with anything in mind as far as I can tell. It sucks as a facade and the implementation is barely adequate. I've delayed creating the bridge from JUL to Log4j 2 primarily because all the ways to do it are bad.
>
>>
>> With this in mind, commons-logging is a better choice as it should be
>> possible to have an entirely contained logging setup within the
>> application and a properly written container shouldn't interfere with
>> this. Commons-logging is also relatively simple to redirect to something
>> else.
>
> That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
Let's make it better then. Pool2 can drive the requirements and we'll
eat our own dog food.
Gary
>>
>> Given the discussion so far has been around commons-logging or
>> java.util.logging, I think these two are the front runners. I can live
>> with either but I have a very narrow focus - i.e. what can i get working
>> easily with Tomcat's packaged renamed version of pool2.
>
> I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty well.
>
>>
>> Taking a wider view, commons-logging is probably the better choice as
>> although it adds a dependency, it is easier for folks to integrate with
>> their logging framework of choice.
>>
>
> Yes, it is a much better choice than JUL just because of that.
>
> Ralph
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS][POOL] Logging options for Pool2
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:
>>
>
> Yeah, that isn't going to work. I really do wish java.util.logging had
> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
> this in Tomcat but even with JULI the APIs just aren't available to do
> this. You could do JVM specific hacks but they will break just as soon
> as the JVM vendor changes their internal API (as they are perfectly
> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
Sorry, JUL wasn't designed with anything in mind as far as I can tell. It sucks as a facade and the implementation is barely adequate. I've delayed creating the bridge from JUL to Log4j 2 primarily because all the ways to do it are bad.
>
> With this in mind, commons-logging is a better choice as it should be
> possible to have an entirely contained logging setup within the
> application and a properly written container shouldn't interfere with
> this. Commons-logging is also relatively simple to redirect to something
> else.
That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
>
> Given the discussion so far has been around commons-logging or
> java.util.logging, I think these two are the front runners. I can live
> with either but I have a very narrow focus - i.e. what can i get working
> easily with Tomcat's packaged renamed version of pool2.
I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty well.
>
> Taking a wider view, commons-logging is probably the better choice as
> although it adds a dependency, it is easier for folks to integrate with
> their logging framework of choice.
>
Yes, it is a much better choice than JUL just because of that.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Mark Thomas <ma...@apache.org>.
On 10/02/2012 13:25, Jörg Schaible wrote:
> Hi,
>
> markt@apache.org wrote:
>
>> Gary Gregory <ga...@gmail.com> wrote:
>>
>>> On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 10/02/2012 00:20, Simone Tripodi wrote:
>>>>> I have a preference fo juli.
>>>> I can work with that.
>>>
>>> Is a dependency on JULI better than on common-logging?
>>>
>>> Or is there some confusion talking about JUL vs JULI?
>>
>> I was assuming java.util.logging rather than Tomcat's logging library
>> JULI.
>
> And how do you intend then to manage the log output in an enterprise
> environment? Implement an own JUL-fomatter, deploy it with your web
> application and try to use it.
Yeah, that isn't going to work. I really do wish java.util.logging had
been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
this in Tomcat but even with JULI the APIs just aren't available to do
this. You could do JVM specific hacks but they will break just as soon
as the JVM vendor changes their internal API (as they are perfectly
entitled to do). In the end, Tomcat categorized this problem as WONTFIX.
With this in mind, commons-logging is a better choice as it should be
possible to have an entirely contained logging setup within the
application and a properly written container shouldn't interfere with
this. Commons-logging is also relatively simple to redirect to something
else.
Given the discussion so far has been around commons-logging or
java.util.logging, I think these two are the front runners. I can live
with either but I have a very narrow focus - i.e. what can i get working
easily with Tomcat's packaged renamed version of pool2.
Taking a wider view, commons-logging is probably the better choice as
although it adds a dependency, it is easier for folks to integrate with
their logging framework of choice.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 10, 2012, at 7:40 AM, Emmanuel Bourg wrote:
> Le 10/02/2012 16:22, Gary Gregory a écrit :
>
>> This would be good to know: What is the performance hit of the two
>> solutions above?
>>
>> The question becomes: should pool2 depend on CL?
>
> Bridging JUL is probably not the most efficient solution, but if the application is not very log intensive I think it's ok.
>
> For [pool2] I suggest using JUL.
Sorry, I suggest never using JUL unless it is a standalone app. Never use it in a library. Many people bridge the APIs and JUL is very inefficient to do.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/02/2012 16:22, Gary Gregory a écrit :
> This would be good to know: What is the performance hit of the two
> solutions above?
>
> The question becomes: should pool2 depend on CL?
Bridging JUL is probably not the most efficient solution, but if the
application is not very log intensive I think it's ok.
For [pool2] I suggest using JUL.
Emmanuel Bourg
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Feb 10, 2012 at 10:15 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 10/02/2012 15:53, Gary Gregory a écrit :
>
>
> When it is integration time, we'll need some guidance even if it is just
>> pointers to HOW-TOs. In my case, what happens when my server to coded to
>> Log4J and I want all logging to go to the same file? I do not need an
>> answer now but it will be an issue.
>>
>
> I do that with the JUL/Log4J bridge:
>
> http://people.apache.org/~**psmith/logging.apache.org/**
> sandbox/jul-log4j-bridge/**examples.html<http://people.apache.org/%7Epsmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html>
>
> Example 1 - Completely take over JUL and route all LogRecords into log4j
>
> JULLog4jBridge.assimilate();
>
>
> Example 4 - Completely take over JUL and route all LogRecords into log4j
> by using a System property
>
> ...-Djava.util.logging.**manager=org.apache.logging.**julbridge.JULBridgeLogManager
> ...
>
>
>
Good stuff, thank you.
So both JUL and CL can work with Log4J and presumably any other logging
implementation.
This would be good to know: What is the performance hit of the two
solutions above?
The question becomes: should pool2 depend on CL?
Gary
> Emmanuel Bourg
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/02/2012 15:53, Gary Gregory a écrit :
> When it is integration time, we'll need some guidance even if it is just
> pointers to HOW-TOs. In my case, what happens when my server to coded to
> Log4J and I want all logging to go to the same file? I do not need an
> answer now but it will be an issue.
I do that with the JUL/Log4J bridge:
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Example 1 - Completely take over JUL and route all LogRecords into log4j
JULLog4jBridge.assimilate();
Example 4 - Completely take over JUL and route all LogRecords into log4j
by using a System property
...-Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager
...
Emmanuel Bourg
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Gary Gregory <ga...@gmail.com>.
Hi All,
If we do logging, JUL is acceptable of course. So is commons-logging.
When it is integration time, we'll need some guidance even if it is just
pointers to HOW-TOs. In my case, what happens when my server to coded to
Log4J and I want all logging to go to the same file? I do not need an
answer now but it will be an issue.
Gary
On Fri, Feb 10, 2012 at 8:25 AM, Jörg Schaible
<Jo...@scalaris.com>wrote:
> Hi,
>
> markt@apache.org wrote:
>
> > Gary Gregory <ga...@gmail.com> wrote:
> >
> >>On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> On 10/02/2012 00:20, Simone Tripodi wrote:
> >>>> I have a preference fo juli.
> >>> I can work with that.
> >>
> >>Is a dependency on JULI better than on common-logging?
> >>
> >>Or is there some confusion talking about JUL vs JULI?
> >
> > I was assuming java.util.logging rather than Tomcat's logging library
> > JULI.
>
> And how do you intend then to manage the log output in an enterprise
> environment? Implement an own JUL-fomatter, deploy it with your web
> application and try to use it.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi,
markt@apache.org wrote:
> Gary Gregory <ga...@gmail.com> wrote:
>
>>On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
>>
>>> On 10/02/2012 00:20, Simone Tripodi wrote:
>>>> I have a preference fo juli.
>>> I can work with that.
>>
>>Is a dependency on JULI better than on common-logging?
>>
>>Or is there some confusion talking about JUL vs JULI?
>
> I was assuming java.util.logging rather than Tomcat's logging library
> JULI.
And how do you intend then to manage the log output in an enterprise
environment? Implement an own JUL-fomatter, deploy it with your web
application and try to use it.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by ma...@apache.org.
Gary Gregory <ga...@gmail.com> wrote:
>On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
>
>> On 10/02/2012 00:20, Simone Tripodi wrote:
>>> I have a preference fo juli.
>> I can work with that.
>
>Is a dependency on JULI better than on common-logging?
>
>Or is there some confusion talking about JUL vs JULI?
I was assuming java.util.logging rather than Tomcat's logging library JULI.
Mark
>
>Gary
>>
>>> IIRC, Tomcat has a bridge from juli to logging impl,
>> It is actually the other way around. Tomcat uses a package renamed
>> commons-logging hard-coded to output to juli by default. It provides
>a
>> package renamed full commons-logging impl as well for users that want
>to
>> use something else (usually log4j).
>>
>>> it would help to keep [pool] dependencies-less.
>> That is a very big advantage of juli.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Gary Gregory <ga...@gmail.com>.
On Feb 10, 2012, at 5:39, Mark Thomas <ma...@apache.org> wrote:
> On 10/02/2012 00:20, Simone Tripodi wrote:
>> I have a preference fo juli.
> I can work with that.
Is a dependency on JULI better than on common-logging?
Or is there some confusion talking about JUL vs JULI?
Gary
>
>> IIRC, Tomcat has a bridge from juli to logging impl,
> It is actually the other way around. Tomcat uses a package renamed
> commons-logging hard-coded to output to juli by default. It provides a
> package renamed full commons-logging impl as well for users that want to
> use something else (usually log4j).
>
>> it would help to keep [pool] dependencies-less.
> That is a very big advantage of juli.
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [DISCUSS][POOL] Logging options for Pool2
Posted by Mark Thomas <ma...@apache.org>.
On 10/02/2012 00:20, Simone Tripodi wrote:
> I have a preference fo juli.
I can work with that.
> IIRC, Tomcat has a bridge from juli to logging impl,
It is actually the other way around. Tomcat uses a package renamed
commons-logging hard-coded to output to juli by default. It provides a
package renamed full commons-logging impl as well for users that want to
use something else (usually log4j).
> it would help to keep [pool] dependencies-less.
That is a very big advantage of juli.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][POOL] Logging options for Pool2
Posted by Simone Tripodi <si...@apache.org>.
I have a preference fo juli. IIRC, Tomcat has a bridge from juli to
logging impl, it would help to keep [pool] dependencies-less.
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Feb 9, 2012 at 11:25 PM, Mark Thomas <ma...@apache.org> wrote:
> One of the big design decisions left for pool2 is whether or not to add
> logging. If logging is added then that opens up the what to log and with
> which logging framework questions.
>
> I do think some form of logging is required.
>
> See POOL-131 for one example of where logging could be useful.
>
> I have a preference for commons-logging. Partly since it is eating our
> own dog food, partly because it will make updating Tomcat to use pool2
> easier.
>
> I did have a random thought that we could do zero logging but emit JMX
> notifications if JMX was enabled. It avoids the "which framework" debate
> but uses an approach that is far less widely used in my experience.
>
> All this is because I am (hopefully) getting close to the point where
> the pool2 code is ready for an alpha release.
>
> Thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> 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