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 > [email protected] > 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. _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
