You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Ceki Gülcü <ce...@qos.ch> on 2005/01/04 15:28:35 UTC
Consider UGLI
Hello,
After log4j 1.3 is released, you might want to consider UGLI. For
details please see
http://logging.apache.org/log4j/docs/ugli.html
Best regards,
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
You will probably fins UGLI's support for parameterized log messages
interesting. See the question "What is the fastest way of (not)
logging?" in the log4j FAQ for more details.
http://logging.apache.org/log4j/docs/faq.html#2.3
At 03:28 PM 1/4/2005, you wrote:
>Hello,
>
>After log4j 1.3 is released, you might want to consider UGLI. For
>details please see
>
> http://logging.apache.org/log4j/docs/ugli.html
>
>Best regards,
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ortwin Glück <or...@nose.ch>.
The words of the expert. This is fantastic news!
Thanks for your effort
Ortwin Glück
Ceki Gülcü wrote:
>
> Ortwin,
>
> Since the org.apache.log4j.Logger class is a direct implementation of
> org.apache.ugli.ULogger interface, there is no need to wrap a log4j
> Logger to conform to the UGLI interface. Log4j Loggers are already
> ULoggers. It follows that the objects returned by
> o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
> by o.a.log4j.Logger.getLogger("x").
>
> Thus, using UGLI in conjunction with log4j will not carry any overhead
> whatsoever.
>
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string
> ["+query"]." );
> }
>
> you can just write:
>
> logger.debug("User with {} entered wrong query string [{}].", id, query);
>
> Give or take a nano-second, when the log statement is disabled, both
> forms perform equally well but the second form is easier to read and
> to write.
>
> I hope this answers your question.
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ortwin Glück <or...@nose.ch>.
Sam Berlin wrote:
> The antfile also highlighted some other questions -- namely, trace level
> debugging is removed, the isXEnabled methods are removed (in favor of
> isEnabled(Level.X)), and it looks like the replacements are directly
> using log4j instead of ULogger interfaces. Are these changes necessary
> in order to move to UGLI?
No. The Ant file was posted to the list very long ago. I just thought of
it as a starting point, a template. I didn't even look at it longer than
2 seconds... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:42 PM 1/4/2005, you wrote:
>UGLI does look to be nice, but I'm confused about how the parameterized
>log messages can be done without using Java 1.5's varargs construct.
>Does ULogger expose a lot of overloaded functions that can take an extreme
>amount of arguments?
Just look at the code. It's all there.
>The antfile also highlighted some other questions -- namely, trace level
>debugging is removed, the isXEnabled methods are removed (in favor of
>isEnabled(Level.X)), and it looks like the replacements are directly using
>log4j instead of ULogger interfaces. Are these changes necessary in order
>to move to UGLI?
As far as I understand, the antfile is just a template to start things
going, nothing more.
>(My questions are more out of curiosity in moving to UGLI for our own
>project, but I imagine will also have relevance with httpclient.)
>
>Thanks,
> Sam
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Sam Berlin <sb...@limepeer.com>.
UGLI does look to be nice, but I'm confused about how the parameterized
log messages can be done without using Java 1.5's varargs construct.
Does ULogger expose a lot of overloaded functions that can take an
extreme amount of arguments?
The antfile also highlighted some other questions -- namely, trace
level debugging is removed, the isXEnabled methods are removed (in
favor of isEnabled(Level.X)), and it looks like the replacements are
directly using log4j instead of ULogger interfaces. Are these changes
necessary in order to move to UGLI?
(My questions are more out of curiosity in moving to UGLI for our own
project, but I imagine will also have relevance with httpclient.)
Thanks,
Sam
On Jan 4, 2005, at 11:49 AM, Eric Bloch wrote:
>
>
> Ceki Gülcü wrote:
>
>> Ortwin,
>> Since the org.apache.log4j.Logger class is a direct implementation of
>> org.apache.ugli.ULogger interface, there is no need to wrap a log4j
>> Logger to conform to the UGLI interface. Log4j Loggers are already
>> ULoggers. It follows that the objects returned by
>> o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
>> by o.a.log4j.Logger.getLogger("x").
>> Thus, using UGLI in conjunction with log4j will not carry any overhead
>> whatsoever.
>> As noted in my previous message, UGLI also supports parameterized log
>> messages obliterating the need to surround log messages with
>> logger.isXXXEnabled checks.
>> Instead of writing:
>> if(logger.isDebugEnabled()) {
>> logger.debug("User with "+id+" entered wrong query string
>> ["+query"]." );
>> }
>
> Just to be clear, you still suffer the cost of the string allocation
> and assembly, right? I've heard this is better in Java 1.5, but I'm
> not up on that.
>
> I'd love to hear pros/cons on how this compares to commons-logging
> with respect to class-loader problems.
>
> -Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:49 PM 1/4/2005, Eric Bloch wrote:
>Just to be clear, you still suffer the cost of the string allocation and
>assembly, right? I've heard this is better in Java 1.5, but I'm not up on
>that.
Disabled log statements will not incur the cost of string allocation
and assembly. Actually, that is the whole point. Moreover, parameterized
log messages do not depend on JDK 1.5.
>I'd love to hear pros/cons on how this compares to commons-logging with
>respect to class-loader problems.
Since UGLI eschews fancy discovery tricks, it should prove to be much
less prone to class loader headaches. Have a look at the code. It's
all really dumb and simple.
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/
>-Eric
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Eric Bloch <bl...@laszlosystems.com>.
Ceki Gülcü wrote:
>
> Ortwin,
>
> Since the org.apache.log4j.Logger class is a direct implementation of
> org.apache.ugli.ULogger interface, there is no need to wrap a log4j
> Logger to conform to the UGLI interface. Log4j Loggers are already
> ULoggers. It follows that the objects returned by
> o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
> by o.a.log4j.Logger.getLogger("x").
>
> Thus, using UGLI in conjunction with log4j will not carry any overhead
> whatsoever.
>
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string
> ["+query"]." );
> }
Just to be clear, you still suffer the cost of the string allocation and
assembly, right? I've heard this is better in Java 1.5, but I'm not up
on that.
I'd love to hear pros/cons on how this compares to commons-logging with
respect to class-loader problems.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Nicholas Rahn <ni...@mnc.ch>.
Hi Ceki,
does the parameterized log message support mean that log4j 1.3 requires
java 1.5?
thx
nick
ps. sorry if this is a bit off-topic.
On Tue, 2005-01-04 at 17:10 +0100, Ceki Gülcü wrote:
> Ortwin,
>
> Since the org.apache.log4j.Logger class is a direct implementation of
> org.apache.ugli.ULogger interface, there is no need to wrap a log4j
> Logger to conform to the UGLI interface. Log4j Loggers are already
> ULoggers. It follows that the objects returned by
> o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
> by o.a.log4j.Logger.getLogger("x").
>
> Thus, using UGLI in conjunction with log4j will not carry any overhead
> whatsoever.
>
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string ["+query"]." );
> }
>
> you can just write:
>
> logger.debug("User with {} entered wrong query string [{}].", id, query);
>
> Give or take a nano-second, when the log statement is disabled, both
> forms perform equally well but the second form is easier to read and
> to write.
>
> I hope this answers your question.
>
> At 04:37 PM 1/4/2005, Ortwin Glück wrote:
> >Ceki,
> >
> >thanks for the pointer. It's indeed an intersting alternative to
> >commons-logging. Do you have data that compares the performance of UGLI to
> >that of commons-logging when used with Log4J? Especially the cost of not
> >logging a statement would be most interesting.
> >
> >Thanks
> >
> >Ortwin Glück
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
Ortwin,
Since the org.apache.log4j.Logger class is a direct implementation of
org.apache.ugli.ULogger interface, there is no need to wrap a log4j
Logger to conform to the UGLI interface. Log4j Loggers are already
ULoggers. It follows that the objects returned by
o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
by o.a.log4j.Logger.getLogger("x").
Thus, using UGLI in conjunction with log4j will not carry any overhead
whatsoever.
As noted in my previous message, UGLI also supports parameterized log
messages obliterating the need to surround log messages with
logger.isXXXEnabled checks.
Instead of writing:
if(logger.isDebugEnabled()) {
logger.debug("User with "+id+" entered wrong query string ["+query"]." );
}
you can just write:
logger.debug("User with {} entered wrong query string [{}].", id, query);
Give or take a nano-second, when the log statement is disabled, both
forms perform equally well but the second form is easier to read and
to write.
I hope this answers your question.
At 04:37 PM 1/4/2005, Ortwin Glück wrote:
>Ceki,
>
>thanks for the pointer. It's indeed an intersting alternative to
>commons-logging. Do you have data that compares the performance of UGLI to
>that of commons-logging when used with Log4J? Especially the cost of not
>logging a statement would be most interesting.
>
>Thanks
>
>Ortwin Glück
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Consider UGLI
Posted by Ortwin Glück <or...@nose.ch>.
Ceki,
thanks for the pointer. It's indeed an intersting alternative to
commons-logging. Do you have data that compares the performance of UGLI
to that of commons-logging when used with Log4J? Especially the cost of
not logging a statement would be most interesting.
Thanks
Ortwin Glück
Ceki Gülcü wrote:
>
> Hello,
>
> After log4j 1.3 is released, you might want to consider UGLI. For
> details please see
>
> http://logging.apache.org/log4j/docs/ugli.html
>
> Best regards,
>
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org