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
[email protected]
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
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
