[JIRA] Created: (LBCORE-233) Please offer better support for logging "wrappers"
Please offer better support for logging "wrappers" -------------------------------------------------- Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen updated LBCORE-233: ------------------------------- Attachment: LogHelper.java One possible implementation of a Log Helper, showing the String.format() functionality and MDC preprocessing.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen updated LBCORE-233: ------------------------------- Attachment: DeepCallerDataConverter.java showing the class that outputs the desired (non-helper) calling information.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ In putting together the above file attachments, it occurred to me that perhaps DeepCallerDataConverter was unnecessary. Instead of basing FQCN statically in LogHelper on the LogHelper class what if instead, I made LogHelper.FQCN a non-static member equal to the class passed to the LogHelper. Would that render my DeepCallerDataConverter unnecessary? No, it doesn't. Following that idea and replacing with the standard CallerDataConverter showed the LogHelper class. Thus passing a Marker actually doesn't help with what I am trying to do. So DeepCallerDataConverter is, in fact, necessary.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-233: ----------------------------------- Have you looked at the XLogger class [1], in particular its use of LocationAwareLogger class? FYI, logback-classic loggers implement the LocationAwareLogger interface. [1] http://slf4j.org/xref/org/slf4j/ext/XLogger.html
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ No, I'd not looked at XLogger or LocationAwareLogger. It sounds like the approach you are suggesting has the potential to solve my issue without the need to create a special CallerDataConverter. However, I'll admit to being confused. In this method signature: log(Marker marker, String fqcn, ...) what is the role of the marker and what the role of the fqcn? In http://jira.qos.ch/browse/LBCORE-233?focusedCommentId=12266#action_12266 above, I assumed I could create a marker from the FQCN and not need to do all this. Since the slf4j Logger methods no longer had a method as did log4j that included the FQCN as a parameter, I assumed that the marker might be intended as a more flexible replacement for the FQCN which could be used to pass location information. That is what didn't work. I guess I still don't really understand Markers and I think they might be a little better documented than they are. In particular, http://www.slf4j.org/apidocs/index.html?org/slf4j/spi/LocationAwareLogger.ht... leaves the Marker parameter to log totally unexplained. Still, I will give this approach a try.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-233: ----------------------------------- Markers are an under-documented part of logback. For the purposes of issue, just ignore markers and pass 'null' as the marker value when invoking the LocationAwareLogger # log() method.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ A little annoyance of this approach is that LocationAwareLogger.log() requires parameters matching LocationAwareLogger.TRACE_INT, LocationAwareLogger.DEBUG_INT, etc. rather than Level.TRACE_INT, Level.DEBUG_INT etc.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ OK, I've implemented this approach and it's not quite working - when combining this approach with the caller formatter, I find that it shows me a stack trace element one level HIGHER on the stack than I want to see, that is, the line that calls the method where the logging call is issued. I also would like a bit more customizability in the format of the display of the line of stack trace in the caller display. It would be nice if the method to output a line of stack trace text were overridable somehow.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-233: ----------------------------------- It may be logback bug or en error on your end. Could please provide a test case?
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ If I am able to produce such a test case I will open a new issue as we're somewhat far afield from what this started with.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ replicated in a test case. http://jira.qos.ch/browse/LBCLASSIC-305
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ This replication proves to be confusion, as a look at http://jira.qos.ch/browse/LBCLASSIC-305 now indicates. Aside from that, about the only support I still think could be better here are these comments: http://jira.qos.ch/browse/LBCORE-233?focusedCommentId=12270#action_12270 0 is it really impossible to standardize the Level ints between the different implementations or else come up with a conversion method? Code like this: private int getLocationAwareInt(Level level) { switch (level.toInt()) { case Level.TRACE_INT: return LocationAwareLogger.TRACE_INT; case Level.DEBUG_INT: return LocationAwareLogger.DEBUG_INT; case Level.INFO_INT: return LocationAwareLogger.INFO_INT; case Level.WARN_INT: return LocationAwareLogger.WARN_INT; case Level.ERROR_INT: return LocationAwareLogger.ERROR_INT; default: throw new IllegalArgumentException("" + level.toInt() + " not a valid level value"); } } really shouldn't be in user code but part of the library. And it would be nice to make the "Caller +0" notation - which I find slightly annoying to be overridable by overriding the CallerDataConverter class by making it a protected method. Otherwise, my concerns are answered. Thanks.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-233: ----------------------------------- Level class now offers a locationAwareLoggerIntegerToLevel method. See [1]. Protected access getCallerLinePrefix was added to CallerDataConverter in [2]. [1] http://github.com/ceki/logback/commit/8bf8416306 [2] http://github.com/ceki/logback/commit/1cc6703956
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu closed LBCORE-233. ----------------------------- Resolution: Won't Fix
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Logback dev list Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu reopened LBCORE-233: ------------------------------- Assignee: Ceki Gulcu (was: Logback dev list)
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Ceki Gulcu Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu resolved LBCORE-233. ------------------------------- Resolution: Fixed
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Ceki Gulcu Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ RE: http://github.com/ceki/logback/commit/8bf8416306 In order to call LocationAwareLogger.log() you need a LocationAwareLogger.xxxx_INT value, so this change won't help because it goes in the opposite direction, i.e from LocationAwareLoggerInteger to Level. Unless LocationAwareLogger can be rewritten to have an overloaded method that takes an actual Level, which would probably be the best solution, except of course that LAL is an interface so all the implementations would have to be changed.
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Ceki Gulcu Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-233: ----------------------------------- OK, just added a toLocationAwareLoggerInteger method in the Level class [1]. [1] http://github.com/ceki/logback/commit/a2f83e8c0a477
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Ceki Gulcu Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.i... ] Steve Cohen commented on LBCORE-233: ------------------------------------ That'll work! :-)
Please offer better support for logging "wrappers" --------------------------------------------------
Key: LBCORE-233 URL: http://jira.qos.ch/browse/LBCORE-233 Project: logback-core Issue Type: New Feature Reporter: Steve Cohen Assignee: Ceki Gulcu Attachments: DeepCallerDataConverter.java, LogHelper.java
Ceki Gulcu asked me to open this issue in response to a thread on the logback user list: http://mailman.qos.ch/pipermail/logback-user/2011-November/002729.html A common pattern is to funnel logging requests through a "LogHelper" class to add some additional functionalities not supported by log4j or logback. In earlier log4j days I used such a pattern to allow nicer concatenation of parameters, e.g. logHelper.debug(Object ... params) which would concatenate the parameters to build the logging message (using StringBuffer or StringBuilder rather than the "+" operator, which I found much less ugly (and more efficient) than concatenating with plus signs in the main code. Eventually, slf4j offered something of this sort but by then I had already added to my logHelpers, the ability to use java.lang.String.format() to enable printf style logging messages: logHelper.debugf(String format, Object ... params) e.g. logHelper,.debugf("Major Version: %s, Minor Version %s, majorVersion, minorVersion) etc. I preferred mine although what slf4j and logback offer is arguably as good. Or, in certain situations, the log helper may need to put certain information in the MDC. There are lots of reasons to use a logHelper. Another advantage they offer, of somewhat debatable value is that only the helper class needs to reference the real logging framework. This made upgrading from log4j to logback a snap, not that it was all that hard otherwise One area where logback doesn't offer good support for such a pattern is in printing the caller information. My LogHelper class (sample attached), may nest several calls to produce the final result. I don't want any of these calls to appear in the caller information. The only option logback offered was the caller format converter with the depth parameter, but that meant I had to use a depth of 4 to even see the real logging class, while cluttering the log output with 3 absolutely useless lines of LogHelper references. And restricting to a single depth number would also mean that all calls to the logHelper would require the same number of nested internal calls, also not what I wanted. It was easy enough to write a converter (actually stealing Ceki Gulcu's CallerDataConverter class) and modifying it to take, instead of a depth parameter, an FQCN of the logHelper class, which enabled the converter to iterate the stack trace and throw out all the logHelper entries and display what I really wanted to see. I had to steal Ceki's code because some of its methods were private and there was no overridable interface or abstract class that let me do what I wanted.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (2)
-
Ceki Gulcu (JIRA) -
Steve Cohen (JIRA)