[slf4j-dev] Re quest for a log message processing hook.

[ogradyjd]

I did entertain the idea of extending the underlying logging system, but that
ties my code to the underlying logging system.  I was looking for a way to
intercept messages to any underlying logging system, and was going to use
commons logging until I saw the chatter on the net about slf4j.  The point
is that I'd like to get the messages from the abstraction layer so my code
will run with whatever logging system is used, and to do that, I need a hook
into the message processing of either commons logging or slf4j - preferably
before the log message is passed to the underlying logging system. 

As it stands, I'd have to write a wrapper for the "logger" class for either
slf4j or commons logging.  I'd much rather use a hook into the message
processing code, and since commons logging development is, er... stagnant, I
figured I had a better chance with slf4j.  I'd much rather use slf4j
considering it also works with commons logging, which gives my current
employer a migration path.  My employer would not even consider moving from
Log4j to logback right now.  If I were able to use slf4j, however, and still
send the messages to log4j, then the path is much easier to sell.

What do you think?


Ceki Gulcu wrote:
> 
> Hello John,
> 
> Thank you for the praise.
> 
> SLF4J offers very little in terms of functionality beyond the
> abstraction of logging frameworks.  Have you considered extending the
> underlying logging framework, e.g. log4j or logback, instead? I
> believe that logback has the feature you are looking for already
> built-in. See http://logback.qos.ch/manual/filters.html#TurboFilter
> for more details.
> 
> 
> John O'Grady wrote:
>> Hello devs - I love your product, and I'm trying to use it in a special 
>> logging system I'm developing as an open source project.  One of the 
>> things I need for this to work is the ability to intercept messages 
>> being logged by the slf4j framework, ostensibly right after the message 
>> has been "processed" by the inner slf4j workings and before it is sent 
>> to the underlying logging system.
>> 
>> As an example, take this code from
>> org.slf4j.impl.Log4jLoggerAdapter.java:
>> 
>>   public void debug(String format, Object[] argArray) {
>> 
>>     if (logger.isDebugEnabled()) {
>>       String msgStr = MessageFormatter.arrayFormat(format, argArray);
>> 
>>       logger.log(FQCN, Level.DEBUG, msgStr, null);
>>     }
>> 
>>   }
>> 
>> 
>> What I'm looking for would be something like this:
>> 
>>   public void debug(String format, Object[] argArray) {
>> 
>>     sendMsgToListeners(FQCN, Level.DEBUG, format, argArray,
>> logger.isDebugEnabled());
>> 
>>     if(logger.isDebugEnabled()) {
>>       String msgStr = MessageFormatter.arrayFormat(format, argArray);
>> 
>>       logger.log(FQCN, Level.DEBUG, msgStr, null);
>>     }
>> 
>>   }
>> 
>>   private void sendMsgToListeners(String fqcn, String logLvl, String
>> format, Object[] argArray, boolean isLoggable) {
>>     for(LogListener listener : this.logListeners) {
>> 
>>       listener.fire(fqcn, logLvl, format, argArray, isLoggable);
>>     }
>>   }
>> 
>> 
>> That way, other systems could piggyback off of slf4j and make their own 
>> decisions about whether or not they want to process the incoming log 
>> message based on the underlying log setup (logger.isDebugEnabled()) and 
>> their own criteria. Hooks like this would make it easy to add quite a 
>> few other abilities to the framework as well.
>> 
>> So have any of the devs discussed this kind of thing before - do any of 
>> you think it's possible?
>> 
>> 
>> John O'Grady
>> GSI Commerce
>> Facets Technologies
>> 
> 
> -- 
> Ceki Gülcü
> The complete log4j manual: http://www.qos.ch/log4j/
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev
> 
> 

-- 
View this message in context: http://www.nabble.com/Request-for-a-log-message-processing-hook.-tp23724666p23726524.html
Sent from the Slf4J - dev mailing list archive at Nabble.com.