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
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,
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 isEnabled()
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
I did entertain the idea of extending the underlying logging system, but that
ties my code to the underlying logging system. I was looking for a way to
intercept messages to any underlying logging system, and was going to use
commons logging until I saw the chatter on the net about slf4j. The
SLF4J offers very little in terms of functionality beyond the
abstraction of logging frameworks. I should have mentioned that it
does on so on purpose. The message interceptor functionality is not
aligned with that minimalistic philosophy. In short, there very little
chance for the interceptor
I understand. Thanks for the pointers though. I appreciate the help.
Ceki Gulcu wrote:
SLF4J offers very little in terms of functionality beyond the
abstraction of logging frameworks. I should have mentioned that it
does on so on purpose. The message interceptor functionality is not
