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

[Steve Cohen (JIRA)]

    [ http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12266#action_12266 ] 

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