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

[ogradyjd]

Again, I really appreciate all the suggestions.  I'll take a look at
slf4j-simple - it sound like that might be the best way to go rather than
simple class extension.

As for the short circuit code (log.isDebugEnabled()), that becomes much less
of an issue with the slf4j methods like:

  public void trace(String format, Object arg1, Object arg2) {
    if (isTraceEnabled()) {
      String msgStr = MessageFormatter.format(format, arg1, arg2);
      logger.log(FQCN, traceCapable ? Level.TRACE : Level.DEBUG, msgStr,
null);
    }
  }


...which make using the short circuits to save on string concatenation
wastage in the code trying to log a message almost unnecessary. Whatever I
do to grab the log message will have to be before the body of those methods,
however, or else I get short circuited anyway.  I'll let you know what I
come up with.


Mahoney wrote:
> 
> I don't see any way in which SLF4J could reliably help you in the way  
> you want given you often get a structure like this in code:
> 
> if (log.isDebugEnabled()) {
>   log.debug("message");
> }
> 
> The only way you can possibly get the debug message out there is if  
> isDebugEnabled returns true, otherwise the debug method is never going  
> to be called and so no listener would be fired anyway - and there's no  
> way that SLF4J should be returning true there in defiance of the  
> underlying logging system's configuration, the whole point of that  
> method is to prevent possibly costly evaluation of the logic necessary  
> to build the debug message.
> 
> You don't need to subclass; the way SLF4J is designed to provide the  
> flexibility you want is via an implementation.  Write your own SLF4J  
> implementation and you gain access to all the power you need to do  
> anything.  It's pretty easy to do - have a look at slf4j-simple, it's  
> 5 classes, all very small and simple.  And obviously it can wrap the  
> "real" logging system and pass the messages on to it afterwards.
> 
> The other point is that the underlying logging system should already  
> provide the functionality you need - it's just you aren't allowed to  
> use it.  I'm not sure that's really a solid use case for adding new  
> functionality to what is intended to be a very light facade, with the  
> implementation being the configurable, extensible bit.  (The "right"  
> way to do it (in logback/log4j, anyway) is to add a new appender,  
> possibly a custom written one, and configure it so that appender gets  
> all the info you want, whilst maintaining the exact same behaviour for  
> the existing appenders so that they get sent just the same logging  
> messages they always did.  Then there's no question of terabytes of  
> data ending up in existing log files, that data just hits your  
> appender where you can do what you want with it - fire it over a  
> socket, log it to the console, ignore it, whatever.  No admins would  
> need to send you anything.  But I imagine you already know this.)
> 
> 

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