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

Steve Cohen (JIRA) noreply-jira at qos.ch
Mon Nov 7 19:32:12 CET 2011


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

Steve Cohen commented on LBCORE-233:
------------------------------------

This replication proves to be confusion, as a look at http://jira.qos.ch/browse/LBCLASSIC-305 now indicates.

Aside from that, about the only support I still think could be better here are these comments:

http://jira.qos.ch/browse/LBCORE-233?focusedCommentId=12270#action_12270  0 is it really impossible to standardize the Level ints between the different implementations or else come up with a conversion method?  

Code like this:

	private int getLocationAwareInt(Level level) {
		switch (level.toInt()) {
		case Level.TRACE_INT:
			return LocationAwareLogger.TRACE_INT;
		case Level.DEBUG_INT:
			return LocationAwareLogger.DEBUG_INT;
		case Level.INFO_INT:
			return LocationAwareLogger.INFO_INT;
		case Level.WARN_INT:
			return LocationAwareLogger.WARN_INT;
		case Level.ERROR_INT:
			return LocationAwareLogger.ERROR_INT;
		default:
		      throw new IllegalArgumentException("" + level.toInt() + " not a valid level value");
		}

	}
really shouldn't be in user code but part of the library.

And it would be nice to make the "Caller +0" notation - which I find slightly annoying to be overridable by overriding the CallerDataConverter class by making it a protected method.

Otherwise, my concerns are answered.  Thanks.


> 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

        


More information about the logback-dev mailing list