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

[Joern Huxhorn]

Sounds like this could be done at runtime using AOP, e.g.
http://en.wikipedia.org/wiki/AspectJ

Have a look, it could be what you are looking for.

Hope that helps,
Joern.

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
>>
>>
>>     
>
>