You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ralph Goers <ra...@dslextreme.com> on 2009/04/10 18:56:47 UTC
[Configuration] experimental branch uses java.util.logging?
I just noticed that this was changed from commons.logging. I'm very
strongly opposed to using j.u.l. I much prefer a logging abstraction.
While I'm not in love with commons-logging and would prefer SLF4J,
using commons-logging is better than using j.u.l directly. As I said,
if there is some reason for moving away from commons-logging I'd be
happy to do the work to migrate to SLF4J.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 14, 2009, at 2:02 PM, Jörg Schaible wrote:
>
>
>> 2. SLF4J isn't a "direct" replacement for Commons Logging. The APIs
>> aren't exactly the same.
>
> I thought jcl-over-slf4j (or so) is used for that.
Yes - but you lose a lot of the benefits that SLF4J has when you do
that.
>
>
> My main question stays: What does SLF4J offer that we have to use
> now for
> CC? The last time I've checked (well, it must have been CC 1.3 or so),
> logging was used only in one or two places at all anyway.
CC does far too little logging. The code I develop at work uses
SLF4J's XLogger to log the major entry and exits so I can easily
diagnose problems by watching the method flow along with the input
parameters and return values. You don't do this with commons logging
because filtering out the noise is somewhat more difficult and doing
static final String methodName = "doSomething";
if (logger.isTracedEnabled())
{
logger.trace("Entering method" + methodName + ", parm=" + parm);
}
is lots more work than just doing
logger.entry(parm);
I'd be happy to generate some trace logs that show you what this looks
like, but you can also see an example by looking at http://www.slf4j.org/extensions.html#extended_logger
.
>
>
> And Rahul's argument about some consistency between the commons
> component is
> also valid, especially now with CC depending (optionally) on VFS ...
On this I totally agree. But to me the question is, "Is it worth it
to enhance commons logging to do what SLF4J already does?"
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote:
>
> On Apr 14, 2009, at 9:42 AM, Jörg Schaible wrote:
>
>>
>> the point is, what do we gain by a change to SLF4J? For simple
>> components
>> like the ones in Apache Commons it is enough to have one logging
>> facade.
>> There was a major effort to resolve any problem with CL 1.1.1. Most
>> of its
>> bad reputation was a result of Tomcat using CL itself. Tomcat is
>> using JUL
>> now and I really bet SLF4J would suffer from the same problems if
>> used as
>> base of a JEE server. Additionally, since you can use SLF4J as direct
>> replacement, every user is free to do so.
>>
> Valid points. The main issue I have with Commons Logging is just that
> it is too minimal. But that can easily be addressed. But I do have a
> couple of comments.
> 1. The code was already changed from using Commons Logging as it does
> in trunk to use java.util.logging. Both Oliver and I have stated that
> we dislike that and want to change it to a facade.
I've stated the same.
> So it isn't a
> matter of changing it versus leaving it alone.
Yes, for me it's more a matter of reverting that change ;-)
> 2. SLF4J isn't a "direct" replacement for Commons Logging. The APIs
> aren't exactly the same.
I thought jcl-over-slf4j (or so) is used for that.
My main question stays: What does SLF4J offer that we have to use now for
CC? The last time I've checked (well, it must have been CC 1.3 or so),
logging was used only in one or two places at all anyway.
And Rahul's argument about some consistency between the commons component is
also valid, especially now with CC depending (optionally) on VFS ...
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 15, 2009, at 12:22 AM, Ralph Goers wrote:
>
> On Apr 15, 2009, at 12:08 AM, Jochen Wiedmann wrote:
>
>> Ralph Goers wrote at Mittwoch, 15. April 2009 03:18:
>>
>>> By contrast, SLF4J supports many more variations of these, primarily
>>> because it supports Markers (which I will refer to in a moment). In
>>> addition, SLF4J supports a message syntax that in many cases
>>> eliminates the need to wrap all the logging calls with if
>>> (logger.isXXXEnabled()).
>>
>> All true, but fix me if I'm wrong: My understanding is that SLF4J
>> requires recompiling the sources. That's a blocker, IMO.
>>
>
> Where did you get that idea? Your application has to code to the
> SLF4J API just as it has to code to the Commons Logging API if it is
> using that. They are not identical. However, no code changes are
> required to plug in different logging implementations just as they
> aren't for Commons Logging.
>
Let me be even more specific. You code your application to use SLF4J
(or Commons Logging). You compile it. You then use the wiring
mechanism each uses to select the appropriate logging implementation.
With SLF4J that is done by including an "adpater" jar that bridges
between the SLF4J API and the actual logging implementation. You don't
have to recompile anything to make this work.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 15, 2009, at 12:08 AM, Jochen Wiedmann wrote:
> Ralph Goers wrote at Mittwoch, 15. April 2009 03:18:
>
>> By contrast, SLF4J supports many more variations of these, primarily
>> because it supports Markers (which I will refer to in a moment). In
>> addition, SLF4J supports a message syntax that in many cases
>> eliminates the need to wrap all the logging calls with if
>> (logger.isXXXEnabled()).
>
> All true, but fix me if I'm wrong: My understanding is that SLF4J
> requires recompiling the sources. That's a blocker, IMO.
>
Where did you get that idea? Your application has to code to the
SLF4J API just as it has to code to the Commons Logging API if it is
using that. They are not identical. However, no code changes are
required to plug in different logging implementations just as they
aren't for Commons Logging.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jochen Wiedmann <jo...@gmail.com>.
Ralph Goers wrote at Mittwoch, 15. April 2009 03:18:
> By contrast, SLF4J supports many more variations of these, primarily
> because it supports Markers (which I will refer to in a moment). In
> addition, SLF4J supports a message syntax that in many cases
> eliminates the need to wrap all the logging calls with if
> (logger.isXXXEnabled()).
All true, but fix me if I'm wrong: My understanding is that SLF4J
requires recompiling the sources. That's a blocker, IMO.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Don Brown <do...@gmail.com>.
On Fri, Jun 19, 2009 at 6:50 PM, Emmanuel Bourg<eb...@apache.org> wrote:
> Don Brown a écrit :
>>
>> Sure, but that's kinda my point - many webapps, ours (Atlassian) in
>> particular, cannot assume a specific application server. Our apps
>> must be able to be dropped into any app server, with any other
>> webapps, and still be expected to play nicely. Even inserting a root
>> logger that filters for packages don't help, as another app could be
>> using the same library. Again, all other serious logging libraries
>> support this, what I would label, basic feature. Even commons
>> logging, with all its flaws, allows us to reimplement their API's (in
>> an OSGi environment) to handle the logging, but since JUL is a java.*
>> package, we're stuck.
>
> I wouldn't be surprised if all other application server had the same
> mechanism implemented by Tomcat. Ensuring webapps isolation is a basic
> feature for the servers. That's definitely worth checking though.
They don't, AFAICT. Even if they did, it doesn't really help for us
using OSGi. With Log4j, we control the instances of the Log4j
classes, and therefore, are able to properly configure logging across
multiple classloaders (bundles) that don't inherit from the web app
classloader. Since JUL is in java.*, we have no way to cleanly (or
any other way) configure logging for one webapp and its classloaders
(via an embedded OSGi container, in our case).
Don
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Don Brown a écrit :
> Sure, but that's kinda my point - many webapps, ours (Atlassian) in
> particular, cannot assume a specific application server. Our apps
> must be able to be dropped into any app server, with any other
> webapps, and still be expected to play nicely. Even inserting a root
> logger that filters for packages don't help, as another app could be
> using the same library. Again, all other serious logging libraries
> support this, what I would label, basic feature. Even commons
> logging, with all its flaws, allows us to reimplement their API's (in
> an OSGi environment) to handle the logging, but since JUL is a java.*
> package, we're stuck.
I wouldn't be surprised if all other application server had the same
mechanism implemented by Tomcat. Ensuring webapps isolation is a basic
feature for the servers. That's definitely worth checking though.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Don Brown <do...@gmail.com>.
Sure, but that's kinda my point - many webapps, ours (Atlassian) in
particular, cannot assume a specific application server. Our apps
must be able to be dropped into any app server, with any other
webapps, and still be expected to play nicely. Even inserting a root
logger that filters for packages don't help, as another app could be
using the same library. Again, all other serious logging libraries
support this, what I would label, basic feature. Even commons
logging, with all its flaws, allows us to reimplement their API's (in
an OSGi environment) to handle the logging, but since JUL is a java.*
package, we're stuck.
Don
On Fri, Jun 19, 2009 at 6:22 PM, Emmanuel Bourg<eb...@apache.org> wrote:
> Don Brown a écrit :
>>
>> I'd be happy to be proven wrong, but isn't there one huge disadvantage of
>> JUL - lack of per-webapp configuration? How would one webapp decide to
>> redirect JUL to a file without affecting any other webapp in the same JVM?
>> If this is indeed the case, JUL is a showstopper for any webapp that can't
>> assume they are the only webapp in the JVM, which is just about everyone.
>
> Tomcat supports per webapp JUL configuration. I don't know for the other
> servers.
>
> http://tomcat.apache.org/tomcat-6.0-doc/logging.html
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Don Brown a écrit :
> I'd be happy to be proven wrong, but isn't there one huge disadvantage of
> JUL - lack of per-webapp configuration? How would one webapp decide to
> redirect JUL to a file without affecting any other webapp in the same JVM?
> If this is indeed the case, JUL is a showstopper for any webapp that can't
> assume they are the only webapp in the JVM, which is just about everyone.
Tomcat supports per webapp JUL configuration. I don't know for the other
servers.
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Don Brown <do...@gmail.com>.
I'd be happy to be proven wrong, but isn't there one huge disadvantage of
JUL - lack of per-webapp configuration? How would one webapp decide to
redirect JUL to a file without affecting any other webapp in the same JVM?
If this is indeed the case, JUL is a showstopper for any webapp that can't
assume they are the only webapp in the JVM, which is just about everyone.
Don
On Thu, Jun 18, 2009 at 9:28 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Ralph Goers a écrit :
>
> I disagree on both counts. Logging is critical to everything. Debugging
>> problems can be quite difficult if logging isn't done well. Commons Logging
>> isn't all that sophisticated IMO and using JUL as a facade isn't all that
>> practical and just because it can be done doesn't mean it should be. The
>> problem here is that JUL isn't really meant to be a facade and users picking
>> up Commons Configuration would like Commons Configuration's logging to be
>> integrated with their own. So having a "real" facade is of great benefit as
>> the user will just configure their system for Commons Logging and be done
>> with it. I do this with my applications and haven't yet had to configure a
>> facade for Commons Logging as virtually nothing I am using in my environment
>> uses it. Virtually everything I am picking up uses Commons Logging or SLF4J
>> these days.
>>
>
> And everything ends in log4j, where redirecting JUL requires just one line
> in your configuration.
>
> Commons Logging and SLF4J made sense in a pre-Java 1.4 world. Today they
> are just a hindrance inherited from the past.
>
> Btw I'll happily change my mind if someone demonstrates that the JUL
> bridging isn't viable in production and causes unsolvable memory leaks or
> horrible performances.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Apr 15, 2009 at 2:08 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> My experience with AOP logging solutions is limited but from what I've seen
> it is possible to use AOP mechanisms to enable logging but I haven't seen
> any that allow you to enable and then disable logging as desired while the
> application is running. Once you can do that then you don't need log levels,
> log types, filtering, etc. because it can be injected dynamically. That is
> my nirvana. If you know of such a solution please let me know how to get my
> hands on it!
I've used btrace for that a bit, but it's not convinient enough that
it's made it into "this is how I do things" land yet.
- Aidan
--
Apache Qpid - Give me convenience or give me death
http://qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Ralph Goers wrote at Mittwoch, 15. April 2009 09:20:
>
> On Apr 14, 2009, at 11:40 PM, Jörg Schaible wrote:
>>>
>>
>> Yes and no, since it was never the goal of CL to add additional
>> functionality, but to provide a facade for the lowest common set of
>> functionality (and originally it was Log4J that prevented the
>> addition of
>> the trace level ;-).
>>
>> See, we have some global players as customers and all of them use an
>> own
>> logging framework that provides explicit support for their operation
>> management. However, all provide at least a factory for CL.
>
> More and more of them are supporting SLF4J. Heck, even Apache projects
> are switching.
Well, some global players tend to have a different idea about adapting new
technology into their core frameworks. I am glad, that we could use at
least Java 5 since last fall ;-)
[snip]
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Rahul Akolkar wrote:
> On Fri, Jun 19, 2009 at 11:07 AM, Emmanuel Bourg<eb...@apache.org> wrote:
>> Ralph Goers a écrit :
>>
> <snip/>
>>
>>> 2. In all the various logging discussions that have taken place on this
>>> list in the last few months, many initiated by me, the concensus seems
>>> to be that commons logging is the logging framework that should be used
>>> by commons projects. Although not my preference I will abide by that.
>>
>> The consensus is nobody wants to engage in a heated discussion about
>> logging ever again. We have wasted too much time on this topic.
> <snap/>
>
> Sigh, indeed.
>
>
>> So the default
>> choice wins, that's Commons Logging. But that choice is just inherited
>> from the Java 1.3 compatibility era.
>>
> <snip/>
it is as Don said, in a JEE environment JUL is really the worst choice. We
have some global players as customers and they have all very specific
requirements regarding logging to ensure their monitoring process of the
life systems. This is in the range of using a very special format up to
using their logger framework. If you deliver a EAR or WAR you cannot
control the format of JUL at all, since a JUL-formatter must be available
at the server path. Additionally it is not possible to provide an alternate
implementation. I am quite sure that cc2 with JUL would force us to create
an internal fork. JULI for Tomcat only works *because* they are the server.
> And two principles:
> 1. Minimal disruption. Commons is widely used, such that for released
> components, anything that causes any amount of disruption to users is
> no good.
>
> 2. Communal responsibility. Commons libraries tend to be used in
> bunches. Its good when we are consistent in logging. Historically,
> most Commons libraries have used CL.
If we really want to think about a next generation CL and agree that the
approach SLF4J has taken is te right one, then I'd rather move CL 1.x into
maintenance mode and use SLF4J directly instead of reinventing the wheel.
However, that move should be done then for all commons components because
of reason 2.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jun 19, 2009 at 11:07 AM, Emmanuel Bourg<eb...@apache.org> wrote:
> Ralph Goers a écrit :
>
<snip/>
>
>> 2. In all the various logging discussions that have taken place on this
>> list in the last few months, many initiated by me, the concensus seems to be
>> that commons logging is the logging framework that should be used by commons
>> projects. Although not my preference I will abide by that.
>
> The consensus is nobody wants to engage in a heated discussion about logging
> ever again. We have wasted too much time on this topic.
<snap/>
Sigh, indeed.
> So the default
> choice wins, that's Commons Logging. But that choice is just inherited from
> the Java 1.3 compatibility era.
>
<snip/>
And two principles:
1. Minimal disruption. Commons is widely used, such that for released
components, anything that causes any amount of disruption to users is
no good.
2. Communal responsibility. Commons libraries tend to be used in
bunches. Its good when we are consistent in logging. Historically,
most Commons libraries have used CL.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ralph Goers a écrit :
>> Please don't forget to demonstrate that JUL is unsuitable first.
>>
> 1. This discussion has already proven that to me. But then again, I knew
> that before the discussion started.
That's faith, not fact.
> 2. In all the various logging discussions that have taken place on this
> list in the last few months, many initiated by me, the concensus seems
> to be that commons logging is the logging framework that should be used
> by commons projects. Although not my preference I will abide by that.
The consensus is nobody wants to engage in a heated discussion about
logging ever again. We have wasted too much time on this topic. So the
default choice wins, that's Commons Logging. But that choice is just
inherited from the Java 1.3 compatibility era.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 19, 2009, at 1:53 AM, Emmanuel Bourg wrote:
> ralph.goers @dslextreme.com a écrit :
>
>>> The overhead is acceptable for the limited logging requirements of
>>> Commons
>>> Configuration.
>> 1. You have determined this how?
>> 2. Commons Configuration needs more logging added. I have had
>> difficulty
>> identifying problems because not enough logging is being done. I
>> will be
>> adding this.
>
> 1. Commons Configuration logs errors mainly when a configuration is
> loaded or saved. These errors are rare and when they happen, the few
> nanoseconds you might lose with the logging statements are
> insignificant compared to the time spent in the IO operations.
>
> 2. I just hope you won't add traces to every method calls.
No, I will not go that far.
>
>
>
>> But not for mine. I do plan on reverting configuration2 back to
>> commons
>> logging when I get some time. I'd prefer SLF4J but this list has
>> indicated
>> that commons logging is the preferred logging framework to use for
>> commons
>> projects.
>
> Please don't forget to demonstrate that JUL is unsuitable first.
>
1. This discussion has already proven that to me. But then again, I
knew that before the discussion started.
2. In all the various logging discussions that have taken place on
this list in the last few months, many initiated by me, the concensus
seems to be that commons logging is the logging framework that should
be used by commons projects. Although not my preference I will abide
by that. Then I will spend some time on commons logging when I have
time to see what, if any, improvements can be made.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
ralph.goers @dslextreme.com a écrit :
>> The overhead is acceptable for the limited logging requirements of Commons
>> Configuration.
>
> 1. You have determined this how?
> 2. Commons Configuration needs more logging added. I have had difficulty
> identifying problems because not enough logging is being done. I will be
> adding this.
1. Commons Configuration logs errors mainly when a configuration is
loaded or saved. These errors are rare and when they happen, the few
nanoseconds you might lose with the logging statements are insignificant
compared to the time spent in the IO operations.
2. I just hope you won't add traces to every method calls.
> But not for mine. I do plan on reverting configuration2 back to commons
> logging when I get some time. I'd prefer SLF4J but this list has indicated
> that commons logging is the preferred logging framework to use for commons
> projects.
Please don't forget to demonstrate that JUL is unsuitable first.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
On Thu, Jun 18, 2009 at 10:08 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Ceki Gulcu a écrit :
>
> There is also the overhead of converting each jul event to log4j
>> within the bridge. This overhead can be quite significant. In a
>> production system, you also have to synchronize the level of jul
>> logging with that of log4j. It's feasible but just more additional
>> work.
>>
>
> The overhead is acceptable for the limited logging requirements of Commons
> Configuration.
1. You have determined this how?
2. Commons Configuration needs more logging added. I have had difficulty
identifying problems because not enough logging is being done. I will be
adding this.
>
>
>
> Have you already tested an application with Paul's bridge in production?
>>
>
> No, JUL is good enough for my needs.
But not for mine. I do plan on reverting configuration2 back to commons
logging when I get some time. I'd prefer SLF4J but this list has indicated
that commons logging is the preferred logging framework to use for commons
projects.
Ralph
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Torsten Curdt <tc...@apache.org>.
> My experience with AOP logging solutions is limited but from what I've seen
> it is possible to use AOP mechanisms to enable logging but I haven't seen
> any that allow you to enable and then disable logging as desired while the
> application is running.
Well, that depends what is injected by the AOP weaver.
I am not aware of any good runtime weaving (the usual java class
reloading problem) but when we looked used this approach (years ago!
not sure whether there is now - I doubt it) we found there is a middle
ground you can cover quite well.
Maybe not the "Nirvana" you were referring to - but still quite good.
Anyway - enough ranting :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 15, 2009, at 4:28 AM, Torsten Curdt wrote:
>> Yes. AOP that actually works is the nirvana that folks who love to
>> talk
>> about logging dream about.
>
> Hm ...not sure what you are implying here ...but it felt quite real to
> me when we used it :)
>
> Anyway!
>
My experience with AOP logging solutions is limited but from what I've
seen it is possible to use AOP mechanisms to enable logging but I
haven't seen any that allow you to enable and then disable logging as
desired while the application is running. Once you can do that then
you don't need log levels, log types, filtering, etc. because it can
be injected dynamically. That is my nirvana. If you know of such a
solution please let me know how to get my hands on it!
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Torsten Curdt <tc...@apache.org>.
> Yes. AOP that actually works is the nirvana that folks who love to talk
> about logging dream about.
Hm ...not sure what you are implying here ...but it felt quite real to
me when we used it :)
Anyway!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ceki Gulcu <ce...@qos.ch>.
Emmanuel Bourg wrote:
> Ceki Gulcu a écrit :
> Other people than me are already using Paul's bridge or
> SLF4JBridgeHandler which use the same principle. Did they complain about
> performance issues?
As far as I know, SLF4JBridgeHandler is used to bridge a small number
of logging events generated by jul into SLF4J. In contrast, your
proposal has most logging generated by jul in which case the quantity
of logging events to be bridged would be much higher and thus
impractical. In a nutshell, I think that your approach makes sense
only if the underlying logging framework chosen by the end user
happens to be jul, as in that case bridging would be unnecessary.
> Emmanuel Bourg
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ceki Gulcu a écrit :
> Are you sure that commons logging and SLF4J do not make sense in the
> post-Java 1.4 world if you have not tested the alternative you are
> proposing?
The SLF4J API is certainly nicer than JUL, the logging methods are more
convenient and I wish JUL will be updated some day. But for a small
component like Commons Configuration it's not a compelling reason to
adopt it.
Other people than me are already using Paul's bridge or
SLF4JBridgeHandler which use the same principle. Did they complain about
performance issues?
>> SLF4JBridgeHandler seems to do the job. A kind of plugin to enable it
>> from the logback configuration would be nice.
>
> Duly noted.
Thank you,
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ceki Gulcu <ce...@qos.ch>.
Emmanuel Bourg wrote:
> Ceki Gulcu a écrit :
>
>> Redirecting to jul from log4j assumes that you have log4j.jar on your
>> class path. When you direct from jul to log4j, which is the case you
>> mentioned, then you need log4j.jar plus the bridge code which is
>> located in a different artifact (apache-jul-log4j-bridge). Thus, in
>> addition to apache-jul-log4j-bridge on your class path, you would also
>> need to invoke "JULLog4jBridge.assimilate()" in java (compiled) code,
>> not as a log4j configuration directive.
>
> You can also assimilate by adding this line to the log4j configuration:
>
> <plugin name="julreceiver" class="org.apache.log4j.jul.JULReceiver" />
True. My bad.
>> There is also the overhead of converting each jul event to log4j
>> within the bridge. This overhead can be quite significant. In a
>> production system, you also have to synchronize the level of jul
>> logging with that of log4j. It's feasible but just more additional
>> work.
>
> The overhead is acceptable for the limited logging requirements of
> Commons Configuration.
Indeed, if commons configuration does little logging, then you could
use jul and not worry about performance. However, using jul in the way
you describe is non-idiomatic. I don't think jul to log4j bridging is
a viable option in a large application with lots of active logging.
You seem to be focused on reducing the number of dependencies to a
strict minimum. However, in doing so, you might be making life harder
for your users.
>> Have you already tested an application with Paul's bridge in production?
>
> No, JUL is good enough for my needs.
Are you sure that commons logging and SLF4J do not make sense in the
post-Java 1.4 world if you have not tested the alternative you are
proposing?
>> Logback is a native implementation of the SLF4J API. Among other
>> things, this means that logback is accessed via SLF4J. In other words,
>> if you are using logback, then you are using SLF4J. It also follows
>> that the job of of consolidating various logging frameworks is assumed
>> by SLF4J, not logback. See http://www.slf4j.org/legacy.html
>
> SLF4JBridgeHandler seems to do the job. A kind of plugin to enable it
> from the logback configuration would be nice.
Duly noted.
> Emmanuel Bourg
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ceki Gulcu a écrit :
> Redirecting to jul from log4j assumes that you have log4j.jar on your
> class path. When you direct from jul to log4j, which is the case you
> mentioned, then you need log4j.jar plus the bridge code which is
> located in a different artifact (apache-jul-log4j-bridge). Thus, in
> addition to apache-jul-log4j-bridge on your class path, you would also
> need to invoke "JULLog4jBridge.assimilate()" in java (compiled) code,
> not as a log4j configuration directive.
You can also assimilate by adding this line to the log4j configuration:
<plugin name="julreceiver" class="org.apache.log4j.jul.JULReceiver" />
> There is also the overhead of converting each jul event to log4j
> within the bridge. This overhead can be quite significant. In a
> production system, you also have to synchronize the level of jul
> logging with that of log4j. It's feasible but just more additional
> work.
The overhead is acceptable for the limited logging requirements of
Commons Configuration.
> Have you already tested an application with Paul's bridge in production?
No, JUL is good enough for my needs.
> Logback is a native implementation of the SLF4J API. Among other
> things, this means that logback is accessed via SLF4J. In other words,
> if you are using logback, then you are using SLF4J. It also follows
> that the job of of consolidating various logging frameworks is assumed
> by SLF4J, not logback. See http://www.slf4j.org/legacy.html
SLF4JBridgeHandler seems to do the job. A kind of plugin to enable it
from the logback configuration would be nice.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ceki Gulcu <ce...@qos.ch>.
Emmanuel Bourg wrote:
> Ceki Gulcu a écrit :
>
>>> And everything ends in log4j, where redirecting JUL requires just one
>>> line in your configuration.
>>
>> How so?
>
> http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Redirecting to jul from log4j assumes that you have log4j.jar on your
class path. When you direct from jul to log4j, which is the case you
mentioned, then you need log4j.jar plus the bridge code which is
located in a different artifact (apache-jul-log4j-bridge). Thus, in
addition to apache-jul-log4j-bridge on your class path, you would also
need to invoke "JULLog4jBridge.assimilate()" in java (compiled) code,
not as a log4j configuration directive.
There is also the overhead of converting each jul event to log4j
within the bridge. This overhead can be quite significant. In a
production system, you also have to synchronize the level of jul
logging with that of log4j. It's feasible but just more additional
work.
Have you already tested an application with Paul's bridge in production?
> The same feature in logback would be nice (if it doesn't exist already).
Logback is a native implementation of the SLF4J API. Among other
things, this means that logback is accessed via SLF4J. In other words,
if you are using logback, then you are using SLF4J. It also follows
that the job of of consolidating various logging frameworks is assumed
by SLF4J, not logback. See http://www.slf4j.org/legacy.html
> Emmanuel Bourg
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ceki Gulcu a écrit :
>> And everything ends in log4j, where redirecting JUL requires just one
>> line in your configuration.
>
> How so?
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
The same feature in logback would be nice (if it doesn't exist already).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ceki Gulcu <ce...@qos.ch>.
Emmanuel Bourg wrote:
> Ralph Goers a écrit :
>
>> I disagree on both counts. Logging is critical to everything.
>> Debugging problems can be quite difficult if logging isn't done well.
>> Commons Logging isn't all that sophisticated IMO and using JUL as a
>> facade isn't all that practical and just because it can be done
>> doesn't mean it should be. The problem here is that JUL isn't really
>> meant to be a facade and users picking up Commons Configuration would
>> like Commons Configuration's logging to be integrated with their own.
>> So having a "real" facade is of great benefit as the user will just
>> configure their system for Commons Logging and be done with it. I do
>> this with my applications and haven't yet had to configure a facade
>> for Commons Logging as virtually nothing I am using in my environment
>> uses it. Virtually everything I am picking up uses Commons Logging or
>> SLF4J these days.
>
> And everything ends in log4j, where redirecting JUL requires just one
> line in your configuration.
How so?
> Emmanuel Bourg
>
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] Dependencies (was: experimental branch uses java.util.logging?)
Posted by Emmanuel Bourg <eb...@apache.org>.
Ralph Goers a écrit :
> As for dependencies, removing them for the sake of removing them isn't
> necessarily the right thing to do. For example, I noticed attempts to
> move away from Commons BeanUtils. For the life of me I can't understand
> why anyone would want to do that, especially when the code that replaced
> it was less functional.
Which one ?
Most people come to Commons Configuration for an improved
java.util.Properties. We can't reasonably impose a lot of dependencies
for such a basic need. Some users complained about the size of the
library and its dependencies in the past.
There is another dependency I'd like to remove, it's JXPath. We should
be able to replace it with the javax.xml.xpath API introduced in Java 5.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ralph Goers a écrit :
> I disagree on both counts. Logging is critical to everything. Debugging
> problems can be quite difficult if logging isn't done well. Commons
> Logging isn't all that sophisticated IMO and using JUL as a facade isn't
> all that practical and just because it can be done doesn't mean it
> should be. The problem here is that JUL isn't really meant to be a
> facade and users picking up Commons Configuration would like Commons
> Configuration's logging to be integrated with their own. So having a
> "real" facade is of great benefit as the user will just configure their
> system for Commons Logging and be done with it. I do this with my
> applications and haven't yet had to configure a facade for Commons
> Logging as virtually nothing I am using in my environment uses it.
> Virtually everything I am picking up uses Commons Logging or SLF4J these
> days.
And everything ends in log4j, where redirecting JUL requires just one
line in your configuration.
Commons Logging and SLF4J made sense in a pre-Java 1.4 world. Today they
are just a hindrance inherited from the past.
Btw I'll happily change my mind if someone demonstrates that the JUL
bridging isn't viable in production and causes unsolvable memory leaks
or horrible performances.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 2, 2009, at 1:48 PM, Emmanuel Bourg wrote:
> Ralph Goers a écrit :
>
>> From what I can gather from this conversation:
>> a) This is important to only a small group of us.
>> b) No one is against having CC switch back to Commons Logging.
>> c) Some are very much against using a facade other than Commons
>> Logging, for whatever reason.
>
> I did the change to java.util.logging to reduce the dependencies,
> and because JUL can also be used as a facade as demonstrated by Paul
> Smith with the log4j bridge:
>
> http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
>
> Logging is not critical to Commons Configuration (unlike an
> application server for example), there is no need for a
> sophisticated framework. As a library it shouldn't impose a
> dependency if it can be avoided.
I disagree on both counts. Logging is critical to everything.
Debugging problems can be quite difficult if logging isn't done well.
Commons Logging isn't all that sophisticated IMO and using JUL as a
facade isn't all that practical and just because it can be done
doesn't mean it should be. The problem here is that JUL isn't really
meant to be a facade and users picking up Commons Configuration would
like Commons Configuration's logging to be integrated with their own.
So having a "real" facade is of great benefit as the user will just
configure their system for Commons Logging and be done with it. I do
this with my applications and haven't yet had to configure a facade
for Commons Logging as virtually nothing I am using in my environment
uses it. Virtually everything I am picking up uses Commons Logging or
SLF4J these days.
I just have to rant a little bit more. I'm really trying hard to
understand why you would think logging in an application server is
more important than logging in the applications running in the
application server. If anything, it is the other way around.
Typically, problems in production are not in the app server but in the
application. Furthermore, incorrect configuration information to an
application - especially in a situation like mine where a single
application is running with more than 1800 possible configurations -
can often be the root cause of many application errors.
As for dependencies, removing them for the sake of removing them isn't
necessarily the right thing to do. For example, I noticed attempts to
move away from Commons BeanUtils. For the life of me I can't
understand why anyone would want to do that, especially when the code
that replaced it was less functional.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Emmanuel Bourg <eb...@apache.org>.
Ralph Goers a écrit :
> From what I can gather from this conversation:
> a) This is important to only a small group of us.
> b) No one is against having CC switch back to Commons Logging.
> c) Some are very much against using a facade other than Commons Logging,
> for whatever reason.
I did the change to java.util.logging to reduce the dependencies, and
because JUL can also be used as a facade as demonstrated by Paul Smith
with the log4j bridge:
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Logging is not critical to Commons Configuration (unlike an application
server for example), there is no need for a sophisticated framework. As
a library it shouldn't impose a dependency if it can be avoided.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 15, 2009, at 1:51 AM, Torsten Curdt wrote:
>> I think Ceki's comment at the end is quite pertinent. But in the
>> end, my
>> reaction to that article is pretty much, "I'd love to see a real
>> world
>> example of someone doing that". I doubt you'll find many.
>
> Some people argue that logging itself can be evil because logging too
> much almost hides information. I will not go there but I guess it
> heavily depends how you use logging in the first place.
>
> I was involved in a project where debug logging was activated through
> an aspect. Everything else was essentially error logging. For the
> libraries we used a very simple facade that came with the project. So
> no dependency at all. The actual main project implemented the facade
> and forwarded to the appropriate logging system. Very simple. Using
> the aspect we could easily pick the right class/package and the method
> calls in there. Of course this cannot give you back a debug log in
> retrospect. But I was surprised how well this worked.
>
> Anyway ...enough logging chit-chat :)
>
Yes. AOP that actually works is the nirvana that folks who love to
talk about logging dream about.
From what I can gather from this conversation:
a) This is important to only a small group of us.
b) No one is against having CC switch back to Commons Logging.
c) Some are very much against using a facade other than Commons
Logging, for whatever reason.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Torsten Curdt <tc...@apache.org>.
> I think Ceki's comment at the end is quite pertinent. But in the end, my
> reaction to that article is pretty much, "I'd love to see a real world
> example of someone doing that". I doubt you'll find many.
Some people argue that logging itself can be evil because logging too
much almost hides information. I will not go there but I guess it
heavily depends how you use logging in the first place.
I was involved in a project where debug logging was activated through
an aspect. Everything else was essentially error logging. For the
libraries we used a very simple facade that came with the project. So
no dependency at all. The actual main project implemented the facade
and forwarded to the appropriate logging system. Very simple. Using
the aspect we could easily pick the right class/package and the method
calls in there. Of course this cannot give you back a debug log in
retrospect. But I was surprised how well this worked.
Anyway ...enough logging chit-chat :)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 15, 2009, at 1:01 AM, Jörg Schaible wrote:
> Jochen Wiedmann wrote at Mittwoch, 15. April 2009 09:32:
>
>> On Wed, Apr 15, 2009 at 9:20 AM, Ralph Goers <ralph.goers@dslextreme.com
>> >
>> wrote:
>>
>>> More and more of them are supporting SLF4J. Heck, even Apache
>>> projects
>>> are switching.
>>
>> IMO, that decision is fine, if the "Apache project" delivers, for
>> example, a complete container like Tomcat. But a component should
>> (again, this is my personal opinion) be easily integrable into any
>> container and its logging system. Recompilation is not (once more, my
>> opinion) easily integrable. In other words, if the "Apache project"
>> is
>> a component, then I'd criticize the decision.
>
> +1
>
I'm +1 for that too. But it is a non-issue since none of the options
require recompilation.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Jochen Wiedmann wrote at Mittwoch, 15. April 2009 09:32:
> On Wed, Apr 15, 2009 at 9:20 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> More and more of them are supporting SLF4J. Heck, even Apache projects
>> are switching.
>
> IMO, that decision is fine, if the "Apache project" delivers, for
> example, a complete container like Tomcat. But a component should
> (again, this is my personal opinion) be easily integrable into any
> container and its logging system. Recompilation is not (once more, my
> opinion) easily integrable. In other words, if the "Apache project" is
> a component, then I'd criticize the decision.
+1
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Apr 15, 2009 at 9:20 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> More and more of them are supporting SLF4J. Heck, even Apache projects are
> switching.
IMO, that decision is fine, if the "Apache project" delivers, for
example, a complete container like Tomcat. But a component should
(again, this is my personal opinion) be easily integrable into any
container and its logging system. Recompilation is not (once more, my
opinion) easily integrable. In other words, if the "Apache project" is
a component, then I'd criticize the decision.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 14, 2009, at 11:40 PM, Jörg Schaible wrote:
>>
>
> Yes and no, since it was never the goal of CL to add additional
> functionality, but to provide a facade for the lowest common set of
> functionality (and originally it was Log4J that prevented the
> addition of
> the trace level ;-).
>
> See, we have some global players as customers and all of them use an
> own
> logging framework that provides explicit support for their operation
> management. However, all provide at least a factory for CL.
More and more of them are supporting SLF4J. Heck, even Apache projects
are switching.
>
>
> As long as you are building an application you have simply more
> freedom to
> select an appropriate logging framework, but for small components
> (as I
> consider all components of Apache Commons) you should not force
> unnecessary
> incompatibilities. Especially since log messages from such basic
> components
> might turn out simply to have a too fine granularity
> (http://wiki.apache.org/avalon/AvalonNoLogging#head-8d74a8d8ad3e97bdc2f9273f97463de06272c59c
> ).
> While I am not conforming to the complete article, it has some valid
> points
> to consider.
>
I think Ceki's comment at the end is quite pertinent. But in the end,
my reaction to that article is pretty much, "I'd love to see a real
world example of someone doing that". I doubt you'll find many.
It has gotten to the point with SLF4J that NOT logging is extremely
cheap.On some tests I ran a year or two ago I showed that NOT logging
1 million records incurred a few hundreths of a second of CPU on my
desktop machine. That is insignificant noise. But the benefits of
being able to go in and set "java.lang" (or any other package) to
debug when you are trying to diagnose a significant problem are
incredibly valuable. I know this because I am encountering this
problem right now. Commons Configuration just does way too little
logging to help diagnose problems at runtime. I am having to create
what I think is a matching scenario for a use case and then see if the
error happens and then finally run it under the debugger to actually
figure out what the problem is.
Again, I have no problem reverting back to Commons Logging if that is
what the community prefers.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote at Mittwoch, 15. April 2009 03:18:
[snip]
> Commons Logging's Log method has very few methods - 2 variations for
> each of the 6 log levels and then the "is" methods.
>
> By contrast, SLF4J supports many more variations of these, primarily
> because it supports Markers (which I will refer to in a moment). In
> addition, SLF4J supports a message syntax that in many cases
> eliminates the need to wrap all the logging calls with if
> (logger.isXXXEnabled()).
>
> Next, SLF4J supports the MDC - regardless of whether the
> implementation comes from Log4j or Logback. My applications all rely
> on this.
>
> The we get to the SLF4J extensions (where I have commit rights).
> XLogger provides some of the APIs that are available in JUL. It uses
> Markers to make it easy to filter them. It also provides an
> MDCStrLookup that allows the MDC to be accessible in any application
> that uses Commons Lang's StrLookup support - which Commons
> Configuration does.
>
> SLF4J also comes with a few utilities such as a profiler and a
> StopWatch class.
>
> Does that help?
Yes and no, since it was never the goal of CL to add additional
functionality, but to provide a facade for the lowest common set of
functionality (and originally it was Log4J that prevented the addition of
the trace level ;-).
See, we have some global players as customers and all of them use an own
logging framework that provides explicit support for their operation
management. However, all provide at least a factory for CL.
As long as you are building an application you have simply more freedom to
select an appropriate logging framework, but for small components (as I
consider all components of Apache Commons) you should not force unnecessary
incompatibilities. Especially since log messages from such basic components
might turn out simply to have a too fine granularity
(http://wiki.apache.org/avalon/AvalonNoLogging#head-8d74a8d8ad3e97bdc2f9273f97463de06272c59c).
While I am not conforming to the complete article, it has some valid points
to consider.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 14, 2009, at 1:48 PM, Torsten Curdt wrote:
>> Valid points. The main issue I have with Commons Logging is just
>> that it is
>> too minimal. But that can easily be addressed. But I do have a
>> couple of
>> comments.
>
> I always thought people were complaining it does too much ;-)
>
> Trying hard not to get dragged into logging discussions anymore - but
> I am curious: What are you missing?
>
Commons Logging's Log method has very few methods - 2 variations for
each of the 6 log levels and then the "is" methods.
By contrast, SLF4J supports many more variations of these, primarily
because it supports Markers (which I will refer to in a moment). In
addition, SLF4J supports a message syntax that in many cases
eliminates the need to wrap all the logging calls with if
(logger.isXXXEnabled()).
Next, SLF4J supports the MDC - regardless of whether the
implementation comes from Log4j or Logback. My applications all rely
on this.
The we get to the SLF4J extensions (where I have commit rights).
XLogger provides some of the APIs that are available in JUL. It uses
Markers to make it easy to filter them. It also provides an
MDCStrLookup that allows the MDC to be accessible in any application
that uses Commons Lang's StrLookup support - which Commons
Configuration does.
SLF4J also comes with a few utilities such as a profiler and a
StopWatch class.
Does that help?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Torsten Curdt <tc...@apache.org>.
> Valid points. The main issue I have with Commons Logging is just that it is
> too minimal. But that can easily be addressed. But I do have a couple of
> comments.
I always thought people were complaining it does too much ;-)
Trying hard not to get dragged into logging discussions anymore - but
I am curious: What are you missing?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 14, 2009, at 9:42 AM, Jörg Schaible wrote:
>
> the point is, what do we gain by a change to SLF4J? For simple
> components
> like the ones in Apache Commons it is enough to have one logging
> facade.
> There was a major effort to resolve any problem with CL 1.1.1. Most
> of its
> bad reputation was a result of Tomcat using CL itself. Tomcat is
> using JUL
> now and I really bet SLF4J would suffer from the same problems if
> used as
> base of a JEE server. Additionally, since you can use SLF4J as direct
> replacement, every user is free to do so.
>
Valid points. The main issue I have with Commons Logging is just that
it is too minimal. But that can easily be addressed. But I do have a
couple of comments.
1. The code was already changed from using Commons Logging as it does
in trunk to use java.util.logging. Both Oliver and I have stated that
we dislike that and want to change it to a facade. So it isn't a
matter of changing it versus leaving it alone.
2. SLF4J isn't a "direct" replacement for Commons Logging. The APIs
aren't exactly the same.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Apr 14, 2009 at 12:42 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Ralph,
>
> Ralph Goers wrote:
>
>>
>> On Apr 11, 2009, at 6:20 AM, Jörg Schaible wrote:
>>>>
>>>
>>> Actually I'd be against SLF4J. Additionally I also prefer commons-
>>> logging
>>> compared to j.u.l.
>>>
>> Why would you be against SLF4J? I assume that means if I changed it to
>> use SLF4J you would vote -1 on the code commit? Does that apply to
>> any commons project?
>
> the point is, what do we gain by a change to SLF4J? For simple components
> like the ones in Apache Commons it is enough to have one logging facade.
> There was a major effort to resolve any problem with CL 1.1.1. Most of its
> bad reputation was a result of Tomcat using CL itself. Tomcat is using JUL
> now and I really bet SLF4J would suffer from the same problems if used as
> base of a JEE server. Additionally, since you can use SLF4J as direct
> replacement, every user is free to do so.
>
<snip/>
Theres also the sense of communal responsibility for individual
components whereby IMO having multiple facades used at Commons just
makes for a bigger overall hairiness quotient. Most of Commons uses
CL, if [configuration] moves chances still are that applications will
depend on CL by other means (many of [configuration]'s dependencies
require CL for example). And for those who really want SLF4J, there is
the now-misnamed jcl-over-slf4j.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote:
>
> On Apr 11, 2009, at 6:20 AM, Jörg Schaible wrote:
>>>
>>
>> Actually I'd be against SLF4J. Additionally I also prefer commons-
>> logging
>> compared to j.u.l.
>>
> Why would you be against SLF4J? I assume that means if I changed it to
> use SLF4J you would vote -1 on the code commit? Does that apply to
> any commons project?
the point is, what do we gain by a change to SLF4J? For simple components
like the ones in Apache Commons it is enough to have one logging facade.
There was a major effort to resolve any problem with CL 1.1.1. Most of its
bad reputation was a result of Tomcat using CL itself. Tomcat is using JUL
now and I really bet SLF4J would suffer from the same problems if used as
base of a JEE server. Additionally, since you can use SLF4J as direct
replacement, every user is free to do so.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 11, 2009, at 6:20 AM, Jörg Schaible wrote:
>>
>
> Actually I'd be against SLF4J. Additionally I also prefer commons-
> logging
> compared to j.u.l.
>
Why would you be against SLF4J? I assume that means if I changed it to
use SLF4J you would vote -1 on the code commit? Does that apply to
any commons project?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Jörg Schaible <jo...@gmx.de>.
Oliver Heger wrote:
> Ralph Goers schrieb:
>> I just noticed that this was changed from commons.logging. I'm very
>> strongly opposed to using j.u.l. I much prefer a logging abstraction.
>> While I'm not in love with commons-logging and would prefer SLF4J, using
>> commons-logging is better than using j.u.l directly. As I said, if there
>> is some reason for moving away from commons-logging I'd be happy to do
>> the work to migrate to SLF4J.
>>
>> Ralph
>>
> This change was made by Emmanuel, IIRC for the reason of getting rid of
> a dependency. Personally I was not too happy with this change either.
> IMHO libraries should use logging facades rather than forcing
> applications to use specific logging tools. So we seem to agree in this
> point.
>
> About the abstraction to use I am a bit indifferent. There is this point
> of eating our own dog food (i.e. commons-logging). But if you prefer
> SLF4J (I haven't used it myself), I am not opposed to moving to it.
Actually I'd be against SLF4J. Additionally I also prefer commons-logging
compared to j.u.l.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Oliver Heger <ol...@oliver-heger.de>.
Ralph Goers schrieb:
>
> On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote:
>
>> Ralph Goers schrieb:
>>> I just noticed that this was changed from commons.logging. I'm very
>>> strongly opposed to using j.u.l. I much prefer a logging abstraction.
>>> While I'm not in love with commons-logging and would prefer SLF4J,
>>> using commons-logging is better than using j.u.l directly. As I said,
>>> if there is some reason for moving away from commons-logging I'd be
>>> happy to do the work to migrate to SLF4J.
>>> Ralph
>> This change was made by Emmanuel, IIRC for the reason of getting rid
>> of a dependency. Personally I was not too happy with this change
>> either. IMHO libraries should use logging facades rather than forcing
>> applications to use specific logging tools. So we seem to agree in
>> this point.
>>
>> About the abstraction to use I am a bit indifferent. There is this
>> point of eating our own dog food (i.e. commons-logging). But if you
>> prefer SLF4J (I haven't used it myself), I am not opposed to moving to
>> it.
>
> Glad to hear that we are on the same page.
>
> If we continue to use commons-logging I would want to add a bunch of
> enhancements to it that SLF4J already has. I suspect that this would
> require a new branch of commons logging and I'd probably want the
> minimum version to be Java 5. Since I'm only one guy and stretched very
> thin I'm not sure when I could get to that. But I really would like to.
>
There should be a couple of people around here who are interested in
commons-logging. So it may make sense to start a new thread to discuss
the enhancements you have in mind. Maybe that gives some momentum to
this component.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote:
> Ralph Goers schrieb:
>> I just noticed that this was changed from commons.logging. I'm
>> very strongly opposed to using j.u.l. I much prefer a logging
>> abstraction. While I'm not in love with commons-logging and would
>> prefer SLF4J, using commons-logging is better than using j.u.l
>> directly. As I said, if there is some reason for moving away from
>> commons-logging I'd be happy to do the work to migrate to SLF4J.
>> Ralph
> This change was made by Emmanuel, IIRC for the reason of getting rid
> of a dependency. Personally I was not too happy with this change
> either. IMHO libraries should use logging facades rather than
> forcing applications to use specific logging tools. So we seem to
> agree in this point.
>
> About the abstraction to use I am a bit indifferent. There is this
> point of eating our own dog food (i.e. commons-logging). But if you
> prefer SLF4J (I haven't used it myself), I am not opposed to moving
> to it.
Glad to hear that we are on the same page.
If we continue to use commons-logging I would want to add a bunch of
enhancements to it that SLF4J already has. I suspect that this would
require a new branch of commons logging and I'd probably want the
minimum version to be Java 5. Since I'm only one guy and stretched
very thin I'm not sure when I could get to that. But I really would
like to.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
Posted by Oliver Heger <ol...@oliver-heger.de>.
Ralph Goers schrieb:
> I just noticed that this was changed from commons.logging. I'm very
> strongly opposed to using j.u.l. I much prefer a logging abstraction.
> While I'm not in love with commons-logging and would prefer SLF4J, using
> commons-logging is better than using j.u.l directly. As I said, if there
> is some reason for moving away from commons-logging I'd be happy to do
> the work to migrate to SLF4J.
>
> Ralph
>
This change was made by Emmanuel, IIRC for the reason of getting rid of
a dependency. Personally I was not too happy with this change either.
IMHO libraries should use logging facades rather than forcing
applications to use specific logging tools. So we seem to agree in this
point.
About the abstraction to use I am a bit indifferent. There is this point
of eating our own dog food (i.e. commons-logging). But if you prefer
SLF4J (I haven't used it myself), I am not opposed to moving to it.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org