log4j to logback question
how would I replace log4j's LoggingEvent.getLocationInformation() in logback?
To answer my own question, a partial answer is the "caller" formatting specifier. getLocationInformation() may or may not have been necessary, but with "caller" it no longer is. However, a common pattern is to funnel logging requests through a LogHelper class to add some additional functionalities not supported by log4j or logback. The LogHelper may throw something on the MDC or do some other preprocessing. My LogHelper also adds methods that apply String.format() on the parameters a la printf. Whatever. Many such things are possible. The problem with the caller specifier is that the LogHelper calls (which are nested) are what it displays, not the true caller in the non-logHelper code. The depth parameter allows you to eventually see the "real" code but really we want the logHelper to disappear from the display. That is display only one element - the one we want. I've written a class similar to the ch.qos.logback.classic.pattern.CallerDataConverter (actually I just grabbed the source and modified) so that instead of a depth I pass the FQCN of the LogHelper class and the convert method skips all elements until it finds one that doesn't match this, and it displays that. This works very well, but it would be nice if logback offered a better way to extend its framework to support this kind of conversion. The only reason I had to resort to reuse by copying instead of reuse by inheritance is that CallerDataConverter has some private methods that I needed to call from convert(). If these were protected, it would provide much greater flexibility. Logback should consider supporting such functionality. On 11/02/2011 09:54 PM, Steve Cohen wrote:
how would I replace log4j's LoggingEvent.getLocationInformation() in logback? _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
It sounds like what you want is something like https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMEN... (but for Logback of course) that will let you modify the event. Ralph On Nov 5, 2011, at 8:59 AM, Steve Cohen wrote:
To answer my own question, a partial answer is the "caller" formatting specifier. getLocationInformation() may or may not have been necessary, but with "caller" it no longer is.
However,
a common pattern is to funnel logging requests through a LogHelper class to add some additional functionalities not supported by log4j or logback. The LogHelper may throw something on the MDC or do some other preprocessing. My LogHelper also adds methods that apply String.format() on the parameters a la printf.
Whatever. Many such things are possible.
The problem with the caller specifier is that the LogHelper calls (which are nested) are what it displays, not the true caller in the non-logHelper code. The depth parameter allows you to eventually see the "real" code but really we want the logHelper to disappear from the display. That is display only one element - the one we want.
I've written a class similar to the ch.qos.logback.classic.pattern.CallerDataConverter (actually I just grabbed the source and modified) so that instead of a depth I pass the FQCN of the LogHelper class and the convert method skips all elements until it finds one that doesn't match this, and it displays that. This works very well, but it would be nice if logback offered a better way to extend its framework to support this kind of conversion. The only reason I had to resort to reuse by copying instead of reuse by inheritance is that CallerDataConverter has some private methods that I needed to call from convert(). If these were protected, it would provide much greater flexibility.
Logback should consider supporting such functionality.
On 11/02/2011 09:54 PM, Steve Cohen wrote:
how would I replace log4j's LoggingEvent.getLocationInformation() in logback? _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Steve, Could you please create a jira issue asking for better support for wrappers in logback? It think currently the question is not treated in sufficient detail if at all. On 11/5/2011 4:59 PM, Steve Cohen wrote:
To answer my own question, a partial answer is the "caller" formatting specifier. getLocationInformation() may or may not have been necessary, but with "caller" it no longer is.
However,
a common pattern is to funnel logging requests through a LogHelper class to add some additional functionalities not supported by log4j or logback. The LogHelper may throw something on the MDC or do some other preprocessing. My LogHelper also adds methods that apply String.format() on the parameters a la printf.
Whatever. Many such things are possible.
The problem with the caller specifier is that the LogHelper calls (which are nested) are what it displays, not the true caller in the non-logHelper code. The depth parameter allows you to eventually see the "real" code but really we want the logHelper to disappear from the display. That is display only one element - the one we want.
I've written a class similar to the ch.qos.logback.classic.pattern.CallerDataConverter (actually I just grabbed the source and modified) so that instead of a depth I pass the FQCN of the LogHelper class and the convert method skips all elements until it finds one that doesn't match this, and it displays that. This works very well, but it would be nice if logback offered a better way to extend its framework to support this kind of conversion. The only reason I had to resort to reuse by copying instead of reuse by inheritance is that CallerDataConverter has some private methods that I needed to call from convert(). If these were protected, it would provide much greater flexibility.
Logback should consider supporting such functionality.
On 11/02/2011 09:54 PM, Steve Cohen wrote:
how would I replace log4j's LoggingEvent.getLocationInformation() in logback?
-- Ceki http://twitter.com/#!/ceki
participants (3)
-
ceki -
Ralph Goers -
Steve Cohen