[ 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