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

[ogradyjd]

I think I may have glossed over a major point in what I need to do.  The
logging system has to continue working as it does now, with no knowledge
that the log message stream is being forked.  One of the major problems I'm
trying to get around is that the log files and configurations are under the
purview of system administrators, meaning that changing any given part of
the configuration like a logging level can take a few hours and requires
review of several teams because of the sheer volume of logging output.  I'll
put it to you this way - if I set the root logger to "trace" in production,
we'd fill a terabyte drive in a few minutes.  And I'd still have to wait for
the admins to send me a copy of the logs.

So I cannot change the logging system as it is now in any way, meaning that
the only way I can gain access to all logged messages whether the underlying
logging system is set to accept them or not, is to intercept messages before
the underlying logging system decides to throw them away.  And since our
code uses several logging systems (legacy stuff almost never gets completely
cleaned out), the only way to do this cleanly is to somehow instrument slf4j
or commons logging to give me the log messages they get before they pass
them to the underlying systems.

That's why my only path at this point, barring API hooks into commons
logging or slf4j, is subclassing.  You're sure having hooks in slf4j is
antithetical to its charter?  It sure would make it a heck of a lot more
flexible.  Look at what plugins did for Eclipse and Firefox...


Mahoney wrote:
> 
> Could you write a very lightweight implementation of SLF4J yourself  
> that adds the listener hook and then forwards on to a wrapped "real"  
> SLF4J implementation?  Effectively a decorator pattern for the real  
> SLF4J logger.  This would also allow you to always return true from  
> the isXXXXEnabled() methods, which would otherwise prevent you getting  
> any logging messages inside blocks protected by them.
> 
> One issue I can see with this approach see is that you'd have binding  
> problems - you'd need your decorator SLF4J implementation to be bound  
> as "the" SLF4J implementation, and then have some other mechanism to  
> bind the underlying SLF4J implementation you want to use for the  
> actual logging.  Don't know if you could do anything clever with  
> classloaders there on bootstrap?  Try and ensure that the apps general  
> class loader loads the binding class from your decorator SLF4J  
> implementation's jar, but inside your SL4J implementation you load any  
> implementation of SLF4J on the classpath other than yours?  I confess  
> my knowledge of classloaders isn't really up to answering that  
> question without spiking it out myself.
> 
> Otherwise I have to say it seems more reasonable to set up the  
> underlying logging system with the root logger set to debug and a  
> special appender where you put your code, assuming you are in control  
> of the configuration of the underlying logging system.
> 
> 
> On 27 May 2009, at 15:38, ogradyjd wrote:
> 
>>
>> I don't really want to say exactly what I'm working on right now for  
>> various
>> reasons, but I can tell you my needs.
>>
>> What I'm doing requires me to be able to receive all the messages  
>> being
>> logged, regardless of whether the underlying logging configuration  
>> is set to
>> log them or not.  For instance, if in the code I were to use slf4j  
>> as the
>> logger, and the underlying log system was Log4j, and the Log4j  
>> configuration
>> was set to "warn", I would still want to get copied on logging  
>> messages for
>> "info", "debug", etc...
>>
>> From there, the system I'm writing is going to process the logs in  
>> it's own
>> way, and then send them... somewhere else (he said, mysteriously).   
>> It will
>> be able to process the logs in a more dynamic way and pay attention  
>> to the
>> threads the log messages came from, so changing the configuration  
>> files will
>> be unnecessary.
>>
>> This is why I'm looking for a way to work with the abstraction layer  
>> rather
>> than the underlying log system.  What log messages get processed  
>> will be
>> completely independent of the log system configuration and will be
>> instantaneous.  For the purposes of what I'm doing, consider the log
>> configuration and output files normally generated as unreachable.
>>
>> Does that give you enough reasons why I'm looking for "listener" I  
>> asked
>> about?   No worries though. I understand your software has a  
>> charter, so I
>> will wrap the Logger and LoggerFactory implementations for now,  
>> unless,
>> given the above info, you have better ideas?
>>
>>
>> Ceki Gulcu wrote:
>>>
>>>
>>>
>>> Thorbjoern Ravn Andersen wrote:
>>>>
>>>> Naturally.
>>>>
>>>> Often people who ask a question have gotten stuck on solving a  
>>>> problem
>>>> in a specific way, and ask about how to do the specific way.   
>>>> Knowing
>>>> about the underlying problem may allow an alternate approach which  
>>>> may
>>>> even happen to work better (if at all :) ).
>>>
>>> Indeed, the original problem might lend itself to different type of
>>> solution.
>>>
>>>
>>> -- 
>>> Ceki Gülcü
>>> Logback: The reliable, generic, fast and flexible logging framework  
>>> for
>>> Java.
>>> http://logback.qos.ch
>>> _______________________________________________
>>> 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.-tp23724666p23743814.html
>> Sent from the Slf4J - dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> dev mailing list
>> dev at slf4j.org
>> http://www.slf4j.org/mailman/listinfo/dev
> 
> _______________________________________________
> 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.-tp23724666p23753111.html
Sent from the Slf4J - dev mailing list archive at Nabble.com.