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

[Ceki Gulcu]

If logback were an option, I'd say go with TurboFilters which act as
listener hooks. They are supported by the framework off-the-shelf,
yada, yada, yada.

If you need to support several logging systems, then you could write
your own bindings. They is little code in each binding and the actual
binding mechanism found in slf4j-api is pretty dumb. You might be
surprised at how dumb it is, but otherwise I don't expect that you
would have trouble understanding it.

Cheers,

ogradyjd wrote:
> 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
>>
>>
> 

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch