Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging

[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

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging

[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