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

[Robert Elliot]

Reading your post properly I see my suggestions were otiose - you'd  
already rejected the config possibility and suggested wrapping the  
logger.  Apologies for not paying more attention before leaping in.

On 27 May 2009, at 21:51, Robert Elliot 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