|
Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is
not applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is
debug(String, Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's largest on-demand environmental information management system can help you mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... - is a
bit different and in order to have the correct method, you should write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG
NETWORKS IP DIVISION
WT PRODUCT UNIT
via Trento, 30 20059 Vimercate (MB) Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...] On
Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is
not applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is
debug(String, Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
 Re: Compiler selecting wrong Logger method
<sigh/> I'm a nitwit. I got confused because at my last job we used a
wrapper around slf4j, and the signature of the method was debug(String,
Object...). Out of curiosity, is there a reason why that format wasn't
used? The compiler should be smart enough to call the more specific
debug(String, Object, Object) when appropriate. Changing from Object[]
to Object... should also be backwards-compatible...
Thanks, Marco!
Eric
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...]
On Behalf Of BRESCIANI, MARCO (MARCO)
Sent: Monday, February 06, 2012 8:12 AM
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... -
is a bit different and in order to have the correct method, you should
write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG NETWORKS - IP DIVISION WT
PRODUCT UNIT via Trento, 30 - 20059 Vimercate (MB) - Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...]
On Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is
not applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is
debug(String, Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help
you mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user_________________________________________________
Don't gamble with your environmental information. Learn how the world's largest on-demand environmental information management system can help you mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Ceki has not yet decided on the proper way to do varargs in slf4j. Until
then, no official API.
See http://bugzilla.slf4j.org/show_bug.cgi?id=31 for the full history.
/Thorbjørn
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...] On
Behalf Of Stein, Eric
Sent: 6. februar 2012 14:24
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
<sigh/> I'm a nitwit. I got confused because at my last job we used a
wrapper around slf4j, and the signature of the method was debug(String,
Object...). Out of curiosity, is there a reason why that format wasn't used?
The compiler should be smart enough to call the more specific debug(String,
Object, Object) when appropriate. Changing from Object[] to Object... should
also be backwards-compatible...
Thanks, Marco!
Eric
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...]
On Behalf Of BRESCIANI, MARCO (MARCO)
Sent: Monday, February 06, 2012 8:12 AM
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... - is a
bit different and in order to have the correct method, you should write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG NETWORKS - IP DIVISION WT PRODUCT
UNIT via Trento, 30 - 20059 Vimercate (MB) - Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto: logback-user-bounces@...]
On Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is not
applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is debug(String,
Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Well, I'd be happy to throw my solution in as an option. You, and Ceki, can find more information at http://code.google.com/p/anodyzed There's information in the wiki documents and more on the way when I get a chance. If there's any information you think is missing, please don't hesitate to let me know and I'll do what I can to remedy the situation. Thanks.
(*Chris *)
On Feb 9, 2012 1:00 AM, "Thorbjørn Ravn Andersen" < thunderaxiom@...> wrote:
Ceki has not yet decided on the proper way to do varargs in slf4j. Until
then, no official API.
See http://bugzilla.slf4j.org/show_bug.cgi?id=31 for the full history.
/Thorbjørn
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...] On
Behalf Of Stein, Eric
Sent: 6. februar 2012 14:24
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
<sigh/> I'm a nitwit. I got confused because at my last job we used a
wrapper around slf4j, and the signature of the method was debug(String,
Object...). Out of curiosity, is there a reason why that format wasn't used?
The compiler should be smart enough to call the more specific debug(String,
Object, Object) when appropriate. Changing from Object[] to Object... should
also be backwards-compatible...
Thanks, Marco!
Eric
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of BRESCIANI, MARCO (MARCO)
Sent: Monday, February 06, 2012 8:12 AM
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... - is a
bit different and in order to have the correct method, you should write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG NETWORKS - IP DIVISION WT PRODUCT
UNIT via Trento, 30 - 20059 Vimercate (MB) - Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is not
applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is debug(String,
Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Chris, very intriguing indeed...it looks like a bonus for a framework like logback.
I would be very happy to see it included. Bye Enrico On Thu, Feb 9, 2012 at 17:15, Chris Pratt <thechrispratt@...> wrote:
ppy to throw my solution in
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick
"Hear and forget; see and remember;do and understand."—Mitchel Resnick "He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Could you summarize your solution briefly here for the completeness of the archives? (Personally I’d just be happy with a resolution so I can easily have more than two {}-arguments) /Thorbjørn Well, I'd be happy to throw my solution in as an option. You, and Ceki, can find more information at http://code.google.com/p/anodyzed There's information in the wiki documents and more on the way when I get a chance. If there's any information you think is missing, please don't hesitate to let me know and I'll do what I can to remedy the situation. Thanks.
(*Chris *) On Feb 9, 2012 1:00 AM, "Thorbjørn Ravn Andersen" <thunderaxiom@...> wrote: Ceki has not yet decided on the proper way to do varargs in slf4j. Until
then, no official API.
See http://bugzilla.slf4j.org/show_bug.cgi?id=31 for the full history.
/Thorbjørn
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...] On
Behalf Of Stein, Eric
Sent: 6. februar 2012 14:24
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
<sigh/> I'm a nitwit. I got confused because at my last job we used a
wrapper around slf4j, and the signature of the method was debug(String,
Object...). Out of curiosity, is there a reason why that format wasn't used?
The compiler should be smart enough to call the more specific debug(String,
Object, Object) when appropriate. Changing from Object[] to Object... should
also be backwards-compatible...
Thanks, Marco!
Eric
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of BRESCIANI, MARCO (MARCO)
Sent: Monday, February 06, 2012 8:12 AM
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... - is a
bit different and in order to have the correct method, you should write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG NETWORKS - IP DIVISION WT PRODUCT
UNIT via Trento, 30 - 20059 Vimercate (MB) - Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is not
applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is debug(String,
Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*) 2012/2/13 Thorbjørn Ravn Andersen <thunderaxiom@...>
Could you summarize your solution briefly here for the completeness of the archives?
(Personally I’d just be happy with a resolution so I can easily have more than two {}-arguments)
/Thorbjørn
Well, I'd be happy to throw my solution in as an option. You, and Ceki, can find more information at http://code.google.com/p/anodyzed There's information in the wiki documents and more on the way when I get a chance. If there's any information you think is missing, please don't hesitate to let me know and I'll do what I can to remedy the situation. Thanks.
(*Chris *) On Feb 9, 2012 1:00 AM, "Thorbjørn Ravn Andersen" <thunderaxiom@...> wrote:
Ceki has not yet decided on the proper way to do varargs in slf4j. Until
then, no official API.
See http://bugzilla.slf4j.org/show_bug.cgi?id=31 for the full history.
/Thorbjørn
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...] On
Behalf Of Stein, Eric
Sent: 6. februar 2012 14:24
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
<sigh/> I'm a nitwit. I got confused because at my last job we used a
wrapper around slf4j, and the signature of the method was debug(String,
Object...). Out of curiosity, is there a reason why that format wasn't used?
The compiler should be smart enough to call the more specific debug(String,
Object, Object) when appropriate. Changing from Object[] to Object... should
also be backwards-compatible...
Thanks, Marco!
Eric
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of BRESCIANI, MARCO (MARCO)
Sent: Monday, February 06, 2012 8:12 AM
To: logback users list
Subject: Re: [logback-user] Compiler selecting wrong Logger method
If I'm not wrong, using - Object[] - or the variable list - Object... - is a
bit different and in order to have the correct method, you should write
this:
LOGGER.debug("Hi {} {} {}", new Object[] { arg1, arg2, arg3 });
MARCO BRESCIANI
ALCATEL-LUCENT
SENIOR SW CRAFT TERMINAL DEVELOPMENT ENG NETWORKS - IP DIVISION WT PRODUCT
UNIT via Trento, 30 - 20059 Vimercate (MB) - Italy
Phone: +39 039 686 6279
Fax: +39 039 686 5600
Marco.Bresciani@...
-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]
On Behalf Of Stein, Eric
Sent: Monday, February 06, 2012 1:59 PM
To: logback-user@...
Subject: [logback-user] Compiler selecting wrong Logger method
I'm seeing a funny error when trying to write to logback.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
final String arg1 = "arg1";
final String arg2 = "arg2";
final String arg3 = "arg3";
LOGGER.debug("Hi {} {}", arg1, arg2);
LOGGER.debug("Hi {} {} {}", new String[] { arg1, arg2, arg3 });
LOGGER.debug("Hi {} {} {}", arg1, arg2, arg3);
The last line is giving this error message:
The method debug(Marker, String, Object, Object) in the type Logger is not
applicable for the arguments (String, String, String, String)
I don't see why it isn't using the method whose signature is debug(String,
Object[]), especially given that I'm not using a Marker.
I'm running in Eclipse Indigo, and my classpath looks like this:
logback-classic-1.0.0.jar
logback-core-1.0.0.jar
slf4j-api-1.6.4.jar
Does anybody know why the compiler is using the wrong method?
Thanks,
Eric Stein
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_________________________________________________
Don't gamble with your environmental information. Learn how the world's
largest on-demand environmental information management system can help you
mitigate your operating risk: www.locustec.com.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
+1 !! On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*) _______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*) _______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Well, not exactly. It works just fine with the Log4j/java.util.logging style logging, but it would require refactoring any SLF4j {} based mappings. Then again, if it was added as an additional option rather than a replacement, that problem would go away as well. If you could continue to get the Logger instances from the LoggerFactory, or a new Log instance that used my format, you could slowly transition to the "new & improved" without requiring a wholesale change.
(*Chris*) On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19@...> wrote:
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*)
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
Actually, I meant the refactoring of a class that was being used by a "new & improved" formatted string. If, for example, I had this formatted string: log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
and down the road, someone decides to remove the number field from the Student class without realizing it was in use here, the code would compile just fine, but the effect (presumably an exception) would not be noticed until this log statement was executed.
On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt@...> wrote:
Well, not exactly. It works just fine with the Log4j/java.util.logging style logging, but it would require refactoring any SLF4j {} based mappings. Then again, if it was added as an additional option rather than a replacement, that problem would go away as well. If you could continue to get the Logger instances from the LoggerFactory, or a new Log instance that used my format, you could slowly transition to the "new & improved" without requiring a wholesale change.
(*Chris*)
On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19@...> wrote:
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*)
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
That's a good point, right now it would eat the exception (logging should never interfere with the operation of a possibly production system) and just log a "null" for that value, which isn't as helpful as it could be. Maybe I could have it log "missing value:0.number" or something like that.
(*Chris*) On Mon, Feb 13, 2012 at 9:44 AM, Tony Trinh <tony19@...> wrote:
Actually, I meant the refactoring of a class that was being used by a "new & improved" formatted string. If, for example, I had this formatted string:log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
and down the road, someone decides to remove the number field from the Student class without realizing it was in use here, the code would compile just fine, but the effect (presumably an exception) would not be noticed until this log statement was executed.
On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt@...> wrote:
Well, not exactly. It works just fine with the Log4j/java.util.logging style logging, but it would require refactoring any SLF4j {} based mappings. Then again, if it was added as an additional option rather than a replacement, that problem would go away as well. If you could continue to get the Logger instances from the LoggerFactory, or a new Log instance that used my format, you could slowly transition to the "new & improved" without requiring a wholesale change.
(*Chris*)
On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19@...> wrote:
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*)
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
That seems reasonable to me, but instead of "null" (which could be a legitimate value), how about an error string that stands out? I suppose the refactoring inconvenience is minor after all, and the advantages perhaps outweigh it, especially with your suggested warning print-out.
-Tony
On Mon, Feb 13, 2012 at 1:10 PM, Chris Pratt <thechrispratt@...> wrote:
That's a good point, right now it would eat the exception (logging should never interfere with the operation of a possibly production system) and just log a "null" for that value, which isn't as helpful as it could be. Maybe I could have it log "missing value:0.number" or something like that.
(*Chris*)On Mon, Feb 13, 2012 at 9:44 AM, Tony Trinh <tony19@...> wrote:
Actually, I meant the refactoring of a class that was being used by a "new & improved" formatted string. If, for example, I had this formatted string:log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
and down the road, someone decides to remove the number field from the Student class without realizing it was in use here, the code would compile just fine, but the effect (presumably an exception) would not be noticed until this log statement was executed.
On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt@...> wrote:
Well, not exactly. It works just fine with the Log4j/java.util.logging style logging, but it would require refactoring any SLF4j {} based mappings. Then again, if it was added as an additional option rather than a replacement, that problem would go away as well. If you could continue to get the Logger instances from the LoggerFactory, or a new Log instance that used my format, you could slowly transition to the "new & improved" without requiring a wholesale change.
(*Chris*)
On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19@...> wrote:
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*)
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
|
Re: Compiler selecting wrong Logger method
I like the idea of making it obvious when there is no value for an existing field (i.e. "null") and when there is no way to get to the field (e.g. "???0.number???"). I'll have to look into making that happen.
(*Chris*) On Mon, Feb 13, 2012 at 11:09 AM, Tony Trinh <tony19@...> wrote:
That seems reasonable to me, but instead of "null" (which could be a legitimate value), how about an error string that stands out? I suppose the refactoring inconvenience is minor after all, and the advantages perhaps outweigh it, especially with your suggested warning print-out.
-Tony
On Mon, Feb 13, 2012 at 1:10 PM, Chris Pratt <thechrispratt@...> wrote:
That's a good point, right now it would eat the exception (logging should never interfere with the operation of a possibly production system) and just log a "null" for that value, which isn't as helpful as it could be. Maybe I could have it log "missing value:0.number" or something like that.
(*Chris*)On Mon, Feb 13, 2012 at 9:44 AM, Tony Trinh <tony19@...> wrote:
Actually, I meant the refactoring of a class that was being used by a "new & improved" formatted string. If, for example, I had this formatted string:log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
and down the road, someone decides to remove the number field from the Student class without realizing it was in use here, the code would compile just fine, but the effect (presumably an exception) would not be noticed until this log statement was executed.
On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt@...> wrote:
Well, not exactly. It works just fine with the Log4j/java.util.logging style logging, but it would require refactoring any SLF4j {} based mappings. Then again, if it was added as an additional option rather than a replacement, that problem would go away as well. If you could continue to get the Logger instances from the LoggerFactory, or a new Log instance that used my format, you could slowly transition to the "new & improved" without requiring a wholesale change.
(*Chris*)
On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19@...> wrote:
I'm a fan of this idea (if you couldn't already tell). A couple disadvantages that come to mind is lack of syntax-checking in the string and painful refactoring (it requires the programmer to search every formatted string for correctness). In any case, what would be the appropriate action for syntax errors that are discovered at runtime?
-Tony
On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19@...> wrote:
+1 !!On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt@...> wrote:
Sure, it uses an extension of the java.text.MessageFormat syntax that allows for unlimited formatted varargs, and allows using dot-notation to prevent evaluation of the methods until it's been deemed necessary. With the current libraries (all of them really), you have to evaluate all the javabeans that hold the data you are looking to log before it's decided whether to log the information or not. In other words:
log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate()));
Means that a lot of work is done and discarded when the debug level on this file is set to info or less. SLF4j is a little better, but not much:
log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format(sdnt.getEnrollmentDate())});
Yes, of course you could (and probably should) wrap each and every call to the log system in if(log.isDebugEnabled()) {}. But we all know that is ugly and easy for Jr programmers to forget. My library puts off the evaluation until after it's been decided that the information is necessary, then efficiently outputs the message, like this:
log.debug("Loading Student [{0.number}] {0.name} Enrolled: {0.enrollmentDate,date,yyyy-MM-dd}",student);
No muss, no fuss and the TextFormat utility is completely usable standalone (as well as the advanced dot-notation utilities).
(*Chris*)
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
Logback-user@...
http://mailman.qos.ch/mailman/listinfo/logback-user
|
smime.p7s (8K) 