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
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
