Why is there no way to do something like... logger.error("blah blah {} blah", exception, object); It seems that the only way to pass that in to the logger is to use if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e); or am I mistaken? It seems that this would be a useful function to make available. -Eric
Eric Faden wrote:
Why is there no way to do something like...
logger.error("blah blah {} blah", exception, object);
It seems that the only way to pass that in to the logger is to use
if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e);
or am I mistaken? It seems that this would be a useful function to make available.
No, you are right. Blame the SLF4J API. Those morons!
-Eric
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev den 12-09-2008 20:47:
Eric Faden wrote:
Why is there no way to do something like...
logger.error("blah blah {} blah", exception, object);
It seems that the only way to pass that in to the logger is to use
if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e);
or am I mistaken? It seems that this would be a useful function to make available.
No, you are right. Blame the SLF4J API. Those morons!
I think I'd better elaborate a bit on Ceki's rather brief explanation :) It is notoriously hard to evolutionarily improve an API and get it exactly right at all the intermediate steps. The question is how this _could_ be implemented at all without starting looking at the individual objects in a varargs and do stuff depending on their type (essentially putting the method selection in javac based on method signature inside slf4j instead), as there is the vararg putting stuff in a Object array (and exceptions are objects). If then the last argument is an exception THEN it should be interpreted traditionally with a stacktrace, but then you cannot stuff it in a placeholder (to get the string representation in the message). What this means is basically that the current syntax breaks down, and perhaps that another approach is appropriate. Feel free to open a JIRA issue if you feel this is important enough. Best Regards, Thorbjørn
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev den 12-09-2008 20:47:
Eric Faden wrote:
Why is there no way to do something like...
logger.error("blah blah {} blah", exception, object);
It seems that the only way to pass that in to the logger is to use
if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e);
or am I mistaken? It seems that this would be a useful function to make available.
No, you are right. Blame the SLF4J API. Those morons!
I think I'd better elaborate a bit on Ceki's rather brief explanation :)
It is notoriously hard to evolutionarily improve an API and get it exactly right at all the intermediate steps.
The question is how this _could_ be implemented at all without starting looking at the individual objects in a varargs and do stuff depending on their type (essentially putting the method selection in javac based on method signature inside slf4j instead), as there is the vararg putting stuff in a Object array (and exceptions are objects).
If then the last argument is an exception THEN it should be interpreted traditionally with a stacktrace, but then you cannot stuff it in a placeholder (to get the string representation in the message).
What this means is basically that the current syntax breaks down, and perhaps that another approach is appropriate. Feel free to open a JIRA issue if you feel this is important enough.
Pour your information, Joern Huxhorn has already filed a bug report on this topic http://bugzilla.slf4j.org/show_bug.cgi?id=70 -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
On 13.09.2008, at 12:59, Ceki Gulcu wrote:
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev den 12-09-2008 20:47:
Eric Faden wrote:
Why is there no way to do something like...
logger.error("blah blah {} blah", exception, object);
It seems that the only way to pass that in to the logger is to use
if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e);
or am I mistaken? It seems that this would be a useful function to make available.
No, you are right. Blame the SLF4J API. Those morons!
I think I'd better elaborate a bit on Ceki's rather brief explanation :)
It is notoriously hard to evolutionarily improve an API and get it exactly right at all the intermediate steps.
The question is how this _could_ be implemented at all without starting looking at the individual objects in a varargs and do stuff depending on their type (essentially putting the method selection in javac based on method signature inside slf4j instead), as there is the vararg putting stuff in a Object array (and exceptions are objects).
If then the last argument is an exception THEN it should be interpreted traditionally with a stacktrace, but then you cannot stuff it in a placeholder (to get the string representation in the message).
What this means is basically that the current syntax breaks down, and perhaps that another approach is appropriate. Feel free to open a JIRA issue if you feel this is important enough.
Pour your information, Joern Huxhorn has already filed a bug report on this topic http://bugzilla.slf4j.org/show_bug.cgi?id=70
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
I've recently added that functionality to Lilith ( http://lilith.huxhorn.de/ ) in a pretty transparent way, i.e. the above code would have to look like this: if (logger.isErrorEnabled()) logger.error("blah blah {} blah", object, e); The last argument is used as the Throwable *IF* it is not used up by a placeholder already. So if (logger.isErrorEnabled()) logger.error("blah blah {} blah {}", object, e); would not use e as the Throwable. If you'd like to use both the String representation and the Throwable you'd have to give it as an argument twice if (logger.isErrorEnabled()) logger.error("blah blah {} blah {}", object, e, e); Please keep in mind that e is simply ignored at the moment in case of if (logger.isErrorEnabled()) logger.error("blah blah {} blah", object, e); so I think this is a pretty compatible enhancement. So if you use Lilith and you are using one of the Lilith appenders you'll get what you expect. Joern.
Joern Huxhorn skrev:
So if you use Lilith and you are using one of the Lilith appenders you'll get what you expect.
Looks interesting. Is Lumberjack the old name for Lilith? What exactly does it do? (a logback appender, a log backend?) An introduction for the uninitated like me on the web site would be nice :) -- THorbjørn
You are absolutely right about the lack of website and documentation. Unfortunately, I don't have much spare-time right now... However, there *is* some documentation in the help-section of the app itself. Lilith was formerly called Lumberjack but the name was already taken by another logging-related project on sourceforge so I decided to rename it. All in all, it's a replacement for Chainsaw. It does have it's own appenders which include the ability to send the same (optionally GZIPed) event to multiple recipients, an appender- wide application id (so it's possible to identify the application sending the event, in case there are more than one application running on the same host) and supports parameters with exceptions. I have not updated the parameter handling code to reflect Cekis latest changes, yet. To use my appender, simply add the following dependency to your maven pom file: <dependency> <groupId>de.huxhorn.lilith</groupId> <artifactId>de.huxhorn.lilith.logback.appender.multiplex-classic</ artifactId> <version>0.9.31</version> <scope>runtime</scope> </dependency> and the following too logback.xml: <appender name="multiplex" class ="de.huxhorn.lilith.logback.appender.ClassicMultiplexSocketAppender"> <Compressing>true</Compressing> <!-- will automatically use correct default port --> <ReconnectionDelay>10000</ReconnectionDelay> <IncludeCallerData>true</IncludeCallerData> <RemoteHosts>localhost, 10.200.55.13</RemoteHosts> </appender> You could also, optionally, specify an application id using <ApplicationId>Your identifier</ApplicationId> This has proved to be quite helpful. Hope this helps. Joern. On 14.09.2008, at 16:49, Thorbjørn Ravn Andersen wrote:
Joern Huxhorn skrev:
So if you use Lilith and you are using one of the Lilith appenders you'll get what you expect.
Looks interesting. Is Lumberjack the old name for Lilith? What exactly does it do? (a logback appender, a log backend?)
An introduction for the uninitated like me on the web site would be nice :)
-- THorbjørn _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
As a workaround perhaps you could use org.apache.commons.lang.exception.ExceptionUtils.getFullStackTrace(java.lang.Throwable throwable), which returns a String. Eric Faden wrote:
Why is there no way to do something like...
logger.error("blah blah {} blah", exception, object);
It seems that the only way to pass that in to the logger is to use
if (logger.isErrorEnabled()) logger.error("blah blah " + object.toString() + " blah", e);
or am I mistaken? It seems that this would be a useful function to make available.
-Eric _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (6)
-
Ceki Gulcu -
Eric Faden -
Joern Huxhorn -
Rusty Wright -
Thorbjørn Ravn Andersen -
Thorbjørn Ravn Andersen