You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2005/01/21 18:06:45 UTC
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT]
Logging
Torsten,
We have noticed that over 95% of log statements have zero, one or two
parameters. The additional two methods (per logging level) that have
been introduced in 1.3 and UGLI offer a convenient alternative to the
if(logger.isXXXEnabled() { logger.xxx("some txt"+arg1+"following txt") }
pattern.
Thus, instead of writing
if(logger.isDebugEnabled() {
logger.debug("New temperature is "+newT+" degrees");
}
you can write
logger.debug("New temperature is {} degrees", newT);
I personally typed in several hundred such parameterized log
statements with relative ease. Existing statements can also be
converted with ease.
For the remaining 5% of the cases with 3 or more parameters, the
if(l.isDebugEnabled) is still availalbe.
It's a pity that you should consider parameterized messages as a
hack. Please do not hesitate to continue this discussion on
log4j-user@.
Best regards,
On 2005-01-07 10:30:11, Torsten Curdt wrote:
> As I already said: I don't see the point of this parameter stuff. IMO
> this only leads to mixing of concepts. Some people will use the "{}"
> some won't. To be honest I would not feel very happy with UGLI since
> IMHO this interface is only half-backed. Sorry.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT]
Logging
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:24 AM 1/22/2005, Vic wrote:
>Curt Arnold wrote:
>
>> the implementation of Logger.debug(Object, Object) would check
>> isDebugEnabled() before attempting to expand the template.
>Ah... thx! That's what I was after and it works the way I (and maybe
>others ) have been extending it.
And it only took 28 messages to get the point across. :-)
>.V
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
Posted by Vic <vi...@friendvu.com>.
Curt Arnold wrote:
> the implementation of Logger.debug(Object, Object) would check
> isDebugEnabled() before attempting to expand the template.
>
Ah... thx! That's what I was after and it works the way I (and maybe
others ) have been extending it.
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
Posted by Curt Arnold <ca...@apache.org>.
On Jan 21, 2005, at 4:47 PM, Vic wrote:
>> Thus, instead of writing
>>
>> if(logger.isDebugEnabled() {
>> logger.debug("New temperature is "+newT+" degrees");
>> }
>>
>> you can write
>>
>> logger.debug("New temperature is {} degrees", newT);
>
>
> If you can help me understand why are those 2 the same?
> The 2nd statment does if somehow? It would not evaluate newT and
> String concat?
>
They are not precisely the same, but they are roughly equivalent in
performance. When isDebugEnabled() == false, the first form evaluates
isDebugEnabled and skips over the log statement avoiding the cost of
evaluating "New temperature is "+newT+" degrees".
The second form would call logger.debug(Object, Object), so would incur
the cost of a function call regardless of whether debug is enabled, but
the implementation of Logger.debug(Object, Object) would check
isDebugEnabled() before attempting to expand the template.
So you have:
logger.debug("New temperature is " + newT + "degrees");
cost when debug disabled: method call overhead + string concatentation
overhead
cost when debug enabled: method call overhead + string concatentation
overhead + appender costs
if (logger.isDebugEnabled()) {
logger.debug("New temperature is " + newT + "degrees");
}
cost when debug disabled: logger.isDebugEnabled() evaluation + jump
cost when debug enabled: logger.isDebugEnabled() evaluation + method
call overhead + string concatentation overhead + appender costs
logger.debug("New temperature is {} degrees", newT)
cost when debug disabled: method call overhead + evaluation of
isDebugEnabled() within logger.debug + jump
cost when debug enabled: method call overhead + evaluation of
isDebugEnabled() + template expansion + appender costs
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
Posted by Vic <vi...@friendvu.com>.
Ceki Gülcü wrote:
>
> Torsten,
>
> We have noticed that over 95% of log statements have zero, one or two
> parameters.
Fine.
> Thus, instead of writing
>
> if(logger.isDebugEnabled() {
> logger.debug("New temperature is "+newT+" degrees");
> }
>
> you can write
>
> logger.debug("New temperature is {} degrees", newT);
If you can help me understand why are those 2 the same?
The 2nd statment does if somehow? It would not evaluate newT and String
concat?
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT]
Logging
Posted by Ceki Gülcü <ce...@qos.ch>.
At 01:18 AM 1/25/2005, Torsten Curdt wrote:
>Sure ...I meant getting rid of it inside the source code is good.
>AFAIU that is one of the goals of UGLI
Not exactly. UGLI's goal is to provide a universal and generic logging
interface in order to allow variation in the implementation.
>Well, ...if you see it that way you are right.
>But I would prefer to have *one* way of logging
>and not have to surround my statement as soon
>as my parameter counts increases from 2 to 3.
Consistency is important but so is simplicity. 0, 1 or 2 parameters cover
well over 90+ percent of the cases. Does the current interface cover all
cases with a single approach? No, it does not. However, for all practical
purposes it gets the job done without getting into a mess. Keeping it dumb
and simple is an easily forgotten design principle.
>>I think the UGLI does a decent job on the vast majority of cases with
>>the tools available. Is it perfect? No. Could we add another few
>>method in order to increase n to 3? We could but no one has asked for
>>it yet. :-)
>
>...no what happens if I would ask?
>This would make an incompatible
>interface change. Now if someone
>else wants 4? ...you'll get the point.
In general, people are free to ask but nothing will change unless they
support their case with solid arguments.
>Although getting rid of the commons-logging "magic"
>sound appealing... IIUC UGLI does not do such discovery
>stuff, right?
Don't take my word, look at the code instead:
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/
See also http://logging.apache.org/log4j/docs/ugli.html
>--
>Torten
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT]
Logging
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:42 AM 1/24/2005, Torsten Curdt wrote:
>Hey, Ceki
>
>...how did you come across that thread? :)
It's a public mailing list. :-)
>>We have noticed that over 95% of log statements have zero, one or two
>>parameters.
>
>Of course that is a bit about what the real world
>requirements are.
>
>...but doesn't this depend on the logging ...well,
>style of the developer?
So are you saying you frequently log with 3 or more parameters?
>First off: getting rid of the isBlaEnabled calls is IMO
>a very good thing. IMO it obfuscates the source code ..at
>least to a certain amount.
The isBlaEnabled method are still there, just that for 95% of the
cases they are no longer needed.
>>For the remaining 5% of the cases with 3 or more parameters, the
>>if(l.isDebugEnabled) is still availalbe.
>
>...now this is what I don't like. Somehow we would draw
>a line. Exactly n parameters are supported. Of course
>noone needs 1000 parameters but having a non consistent
>"policy" how to do the logging is not really cool IMO.
The line has been drawn with n=2. What's not consistent? If n <=2,
you use parameterized messages. If n > 2, you use isBlaEnabled.
>I do NOT consider parameterized messages as a hack! ...the
>only thing that I don't like is the fact that the number of
>parameters are defined in the interface.
Welcome to the world of Java.
>Which is due to the nature of java (unless you want
>to pass around an object array) ...but setting this
>fix limitation inside an interface I consider as a
>hack. ...increasing the supported number of
>parameters would be an interface change!
>
>Parameterized messages with JDK 1.5 ...sure!
>...but not for anything below.
I think the UGLI does a decent job on the vast majority of cases with
the tools available. Is it perfect? No. Could we add another few
method in order to increase n to 3? We could but no one has asked for
it yet. :-)
>I would rather considering using
>
> http://just4log.sourceforge.net/
>
>and rewrite my classes on build time.
Sure, that's another option.
>cheers
>--
>Torsten
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org