I love the project and am glad to see the new features added to logging in general. I am willing to write a patch for a feature but before I do I want to make sure it is something you would be interested in. There is no way to get a stack trace when using paramterized logging. The patch I want to add is that if the last parameter is a Throwable then it gets passed to the fitlerAndLog() method as a thorable (instead of throwable being null). To explain in code. log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2, 3, new Throwable() ); This would not cause the Throwable to be logged. So here are my questions - if I added the code to ch.qos.logback.classic.Logger is that something you are interested in? - lacking that any recommendations on how to get this feature built in. Looking forward to your comments and thanks for the great work on a great logging framework... regards, Glen
Hi Glen, Thanks for sharing your idea. I think it makes sense. As you observer, the current API cannot deal with parameterized logging in conjunction with exceptions. However, I do not think it's a serious limitation because: 1) when confronted with exceptions, the performance of evaluating whether to log or not is not that important (as you usually would want to log) 2) if for some odd reason you need the performance in case of exceptions, you can always write if(logger.isErrorEnabled()) { logger.error("User name ["+name+"] does not match", exception); } In summary, although the current API is completely coherent, it meets most needs. More importantly, since logback's core logging API derives from SLF4J, we cannnot change logback's behavior without also changing SLF4J which I am not keen to do. :-) Does the above make sense? Glen Marchesani wrote:
I love the project and am glad to see the new features added to logging in general.
I am willing to write a patch for a feature but before I do I want to make sure it is something you would be interested in.
There is no way to get a stack trace when using paramterized logging. The patch I want to add is that if the last parameter is a Throwable then it gets passed to the fitlerAndLog() method as a thorable (instead of throwable being null).
To explain in code. log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2, 3, new Throwable() );
This would not cause the Throwable to be logged. So here are my questions
- if I added the code to ch.qos.logback.classic.Logger is that something you are interested in?
- lacking that any recommendations on how to get this feature built in.
Looking forward to your comments and thanks for the great work on a great logging framework...
regards, Glen
------------------------------------------------------------------------
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Thanks for your answer Ceki. Your response is very clear. I hadn't realized that this should have been targeted at the SLF4J list thanks for answering it anyway. If you want I can join the SLF4J mailing list and ask it there. I agree it is not a serious limitation. It is a subtle limitation. I am an architect on a large project and we always have to choose the more intuitive route with fewer subtle pitfalls since all developer's won't be logging nuts and understand the very subtle differences between the two examples. Take this logger.debug("Here is the xml for the service request\n {} ", largeXmlDomDocument ); and turn it into this to add an exception logger.debug("Here is the xml for the service request\n" + largeXmlDomDocument , exception ); This could be a time bomb waiting to happen on a production system with debug logging turned off. A very hard to trace performance hit since the lines of code are so seemingly the same. Of the 16 people on our team I would say only 2 developer's would actually be able to catch that and cite it as a change that is a potential performance hit. I completely understand the necessity of not making changes to a core api lightly. What about having inferred throwables be a system property (or some form of config setting)? On 9/3/07, Ceki Gulcu <listid@qos.ch> wrote:
Hi Glen,
Thanks for sharing your idea. I think it makes sense. As you observer, the current API cannot deal with parameterized logging in conjunction with exceptions.
However, I do not think it's a serious limitation because:
1) when confronted with exceptions, the performance of evaluating whether to log or not is not that important (as you usually would want to log)
2) if for some odd reason you need the performance in case of exceptions, you can always write
if(logger.isErrorEnabled()) { logger.error("User name ["+name+"] does not match", exception); }
In summary, although the current API is completely coherent, it meets most needs. More importantly, since logback's core logging API derives from SLF4J, we cannnot change logback's behavior without also changing SLF4J which I am not keen to do. :-)
Does the above make sense?
Glen Marchesani wrote:
I love the project and am glad to see the new features added to logging in general.
I am willing to write a patch for a feature but before I do I want to make sure it is something you would be interested in.
There is no way to get a stack trace when using paramterized logging. The patch I want to add is that if the last parameter is a Throwable then it gets passed to the fitlerAndLog() method as a thorable (instead of throwable being null).
To explain in code. log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2, 3, new
Throwable() );
This would not cause the Throwable to be logged. So here are my questions
- if I added the code to ch.qos.logback.classic.Logger is that something you are interested in?
- lacking that any recommendations on how to get this feature built in.
Looking forward to your comments and thanks for the great work on a great logging framework...
regards, Glen
------------------------------------------------------------------------
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Hi Glen, When I first read your message, for a second I was worried that SLF4J's current API would allow inadvertent hiding exceptions. However, your example logger.debug("Here is the xml ..."+ largeXmlDocument , exception ); is *not* concerned with hidden exceptions but with performance. To be honest, I must say that I am not totally convinced. Exceptions are by definition exceptional meaning that they do not occur frequently. If they don't occur frequently, performance is not such a big issue. Would you agree? However, if for some reason the exception is thrown frequently, you'd pay they cost of converting the "largeXmlDocument" to String even if the log statement was disabled. I find the following case more troublesome: logger.debug("Here is the xml {}", largeXmlDocument, exception ); The exception would be swallowed by the current API. Now, imho that's a timebomb waiting to happen. Glen Marchesani wrote:
Thanks for your answer Ceki. Your response is very clear. I hadn't realized that this should have been targeted at the SLF4J list thanks for answering it anyway. If you want I can join the SLF4J mailing list and ask it there.
I agree it is not a serious limitation. It is a subtle limitation. I am an architect on a large project and we always have to choose the more intuitive route with fewer subtle pitfalls since all developer's won't be logging nuts and understand the very subtle differences between the two examples.
Take this
logger.debug("Here is the xml for the service request\n {} ", largeXmlDomDocument );
and turn it into this to add an exception
logger.debug("Here is the xml for the service request\n" + largeXmlDomDocument , exception );
This could be a time bomb waiting to happen on a production system with debug logging turned off. A very hard to trace performance hit since the lines of code are so seemingly the same. Of the 16 people on our team I would say only 2 developer's would actually be able to catch that and cite it as a change that is a potential performance hit.
I completely understand the necessity of not making changes to a core api lightly. What about having inferred throwables be a system property (or some form of config setting)?
On 9/3/07, *Ceki Gulcu* <listid@qos.ch <mailto:listid@qos.ch>> wrote:
Hi Glen,
Thanks for sharing your idea. I think it makes sense. As you observer, the current API cannot deal with parameterized logging in conjunction with exceptions.
However, I do not think it's a serious limitation because:
1) when confronted with exceptions, the performance of evaluating whether to log or not is not that important (as you usually would want to log)
2) if for some odd reason you need the performance in case of exceptions, you can always write
if(logger.isErrorEnabled()) { logger.error("User name ["+name+"] does not match", exception); }
In summary, although the current API is completely coherent, it meets most needs. More importantly, since logback's core logging API derives from SLF4J, we cannnot change logback's behavior without also changing SLF4J which I am not keen to do. :-)
Does the above make sense?
Glen Marchesani wrote: > I love the project and am glad to see the new features added to logging > in general. > > I am willing to write a patch for a feature but before I do I want to > make sure it is something you would be interested in. > > There is no way to get a stack trace when using paramterized logging. > The patch I want to add is that if the last parameter is a Throwable > then it gets passed to the fitlerAndLog() method as a thorable (instead > of throwable being null). > > To explain in code. > log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2, 3, new > Throwable() ); > > > This would not cause the Throwable to be logged. So here are my questions > > - if I added the code to ch.qos.logback.classic.Logger is that something > you are interested in? > > - lacking that any recommendations on how to get this feature built in. > > > Looking forward to your comments and thanks for the great work on a > great logging framework... > > regards, > Glen > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > logback-dev mailing list > logback-dev@qos.ch <mailto:logback-dev@qos.ch> > http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch <mailto:logback-dev@qos.ch> http://qos.ch/mailman/listinfo/logback-dev
------------------------------------------------------------------------
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Thanks Ceki.. I agree my argument isn't great. I am trying to get you to see the light that implied throwables is a feature that you want to implement. Without it the projects I work on will have to stick with out internal logging api. The point I was making wasn't performance but code migration. Often the people who maintain the code are not as well versed as the people who created it. The point I was making with logger.debug("Here is the xml {}", largeXmlDocument, exception ); Was that with implied exceptions that would be the equivalent of if ( logger.isDebugEnabled() ) { logger.debug("Here is the xml " + largeXmlDocument, exception ); } I agree given the current api's limitations that it is a time bomb and why I am asking for impied exception feature. We have a large number of developers that will undoubtedly think that slf4j is like our existing internal api and make the mistake we both agree is a mistake... On 9/6/07, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Glen,
When I first read your message, for a second I was worried that SLF4J's current API would allow inadvertent hiding exceptions.
However, your example
logger.debug("Here is the xml ..."+ largeXmlDocument , exception );
is *not* concerned with hidden exceptions but with performance. To be honest, I must say that I am not totally convinced. Exceptions are by definition exceptional meaning that they do not occur frequently. If they don't occur frequently, performance is not such a big issue. Would you agree?
However, if for some reason the exception is thrown frequently, you'd pay they cost of converting the "largeXmlDocument" to String even if the log statement was disabled.
I find the following case more troublesome:
logger.debug("Here is the xml {}", largeXmlDocument, exception );
The exception would be swallowed by the current API. Now, imho that's a timebomb waiting to happen.
Glen Marchesani wrote:
Thanks for your answer Ceki. Your response is very clear. I hadn't realized that this should have been targeted at the SLF4J list thanks for answering it anyway. If you want I can join the SLF4J mailing list and ask it there.
I agree it is not a serious limitation. It is a subtle limitation. I am an architect on a large project and we always have to choose the more intuitive route with fewer subtle pitfalls since all developer's won't be logging nuts and understand the very subtle differences between the two examples.
Take this
logger.debug("Here is the xml for the service request\n {} ", largeXmlDomDocument );
and turn it into this to add an exception
logger.debug("Here is the xml for the service request\n" + largeXmlDomDocument , exception );
This could be a time bomb waiting to happen on a production system with debug logging turned off. A very hard to trace performance hit since the lines of code are so seemingly the same. Of the 16 people on our team I would say only 2 developer's would actually be able to catch that and cite it as a change that is a potential performance hit.
I completely understand the necessity of not making changes to a core api lightly. What about having inferred throwables be a system property (or some form of config setting)?
On 9/3/07, *Ceki Gulcu* <listid@qos.ch <mailto:listid@qos.ch>> wrote:
Hi Glen,
Thanks for sharing your idea. I think it makes sense. As you observer, the current API cannot deal with parameterized logging in conjunction with exceptions.
However, I do not think it's a serious limitation because:
1) when confronted with exceptions, the performance of evaluating whether to log or not is not that important (as you usually would want to log)
2) if for some odd reason you need the performance in case of exceptions, you can always write
if(logger.isErrorEnabled()) { logger.error("User name ["+name+"] does not match", exception); }
In summary, although the current API is completely coherent, it meets most needs. More importantly, since logback's core logging API derives from SLF4J, we cannnot change logback's behavior without also changing SLF4J which I am not keen to do. :-)
Does the above make sense?
Glen Marchesani wrote: > I love the project and am glad to see the new features added to logging > in general. > > I am willing to write a patch for a feature but before I do I want to > make sure it is something you would be interested in. > > There is no way to get a stack trace when using paramterized
logging.
> The patch I want to add is that if the last parameter is a
Throwable
> then it gets passed to the fitlerAndLog() method as a thorable (instead > of throwable being null). > > To explain in code. > log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2, 3, new > Throwable() ); > > > This would not cause the Throwable to be logged. So here are my questions > > - if I added the code to ch.qos.logback.classic.Logger is that something > you are interested in? > > - lacking that any recommendations on how to get this feature built in. > > > Looking forward to your comments and thanks for the great work on
a
> great logging framework... > > regards, > Glen > > > > >
------------------------------------------------------------------------
> > _______________________________________________ > logback-dev mailing list > logback-dev@qos.ch <mailto:logback-dev@qos.ch> > http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch <mailto:logback-dev@qos.ch> http://qos.ch/mailman/listinfo/logback-dev
------------------------------------------------------------------------
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
participants (3)
-
Ceki Gulcu -
Ceki Gulcu -
Glen Marchesani