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

[ogradyjd]

AOP? {twitch}  Let's just say I've seen the road called AOP and where it
leads, and though I've seen good uses of it, I've most often seen coders who
wield it unwisely and subsequently damned themselves to the lowest planes of
the Abyss where the souls of VB and PHP scripters and people who talk in
movie theaters languish in eternal agony.  So I try to avoid it.

Programming holy wars aside, I don't really want to tie my little project to
a massive framework it would have to lug around behind it.  I'd like to do
that as much as the SLF4j projecteers would want to.  I appreciate the
suggestion though. :)


Joern Huxhorn-2 wrote:
> 
> 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
>>>
>>>
>>>     
>>
>>   
> 
> _______________________________________________
> 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.-tp23724666p23752869.html
Sent from the Slf4J - dev mailing list archive at Nabble.com.