[logback-dev] [JIRA] Reopened: (LBCORE-233) Please offer better support for logging "wrappers"

[Ceki Gulcu (JIRA)]

     [ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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