I don't see any way in which SLF4J could reliably help you in the way
you want given you often get a structure like this in code:
if (log.isDebugEnabled()) {
log.debug("message");
}
The only way you can possibly get the debug message out there is if
isDebugEnabled returns true, otherwise the debug method is never going
to be called and so no listener would be fired anyway - and there's no
way that SLF4J should be returning true there in defiance of the
underlying logging system's configuration, the whole point of that
method is to prevent possibly costly evaluation of the logic necessary
to build the debug message.
You don't need to subclass; the way SLF4J is designed to provide the
flexibility you want is via an implementation. Write your own SLF4J
implementation and you gain access to all the power you need to do
anything. It's pretty easy to do - have a look at slf4j-simple, it's
5 classes, all very small and simple. And obviously it can wrap the
"real" logging system and pass the messages on to it afterwards.
The other point is that the underlying logging system should already
provide the functionality you need - it's just you aren't allowed to
use it. I'm not sure that's really a solid use case for adding new
functionality to what is intended to be a very light facade, with the
implementation being the configurable, extensible bit. (The "right"
way to do it (in logback/log4j, anyway) is to add a new appender,
possibly a custom written one, and configure it so that appender gets
all the info you want, whilst maintaining the exact same behaviour for
the existing appenders so that they get sent just the same logging
messages they always did. Then there's no question of terabytes of
data ending up in existing log files, that data just hits your
appender where you can do what you want with it - fire it over a
socket, log it to the console, ignore it, whatever. No admins would
need to send you anything. But I imagine you already know this.)
On 28 May 2009, at 01:14, 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 configurations are
under the
purview of system administrators, meaning that changing any given
part of
the configuration like a logging level can take a few hours and
requires
review of several teams because of the sheer volume of logging
output. I'll
put it to you this way - if I set the root logger to "trace" in
production,
we'd fill a terabyte drive in a few minutes. And I'd still have to
wait for
the admins to send me a copy of the logs.
So I cannot change the logging system as it is now in any way,
meaning that
the only way I can gain access to all logged messages whether the
underlying
logging system is set to accept them or not, is to intercept
messages before
the underlying logging system decides to throw them away. And since
our
code uses several logging systems (legacy stuff almost never gets
completely
cleaned out), the only way to do this cleanly is to somehow
instrument slf4j
or commons logging to give me the log messages they get before they
pass
them to the underlying systems.
That's why my only path at this point, barring API hooks into commons
logging or slf4j, is subclassing. You're sure having hooks in slf4j
is
antithetical to its charter? It sure would make it a heck of a lot
more
flexible. Look at what plugins did for Eclipse and Firefox...
Mahoney 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@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@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@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.-tp23724666p23753111.html
Sent from the Slf4J - dev mailing list archive at Nabble.com.
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
