[
http://jira.qos.ch/browse/LBCORE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12268#action_12268
]
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.html
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
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
