[ 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