If logback were an option, I'd say go with TurboFilters which act as
listener hooks. They are supported by the framework off-the-shelf,
yada, yada, yada.
If you need to support several logging systems, then you could write
your own bindings. They is little code in each binding and the actual
bi
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 th
I agree completely too. If exception handling/logging is being done in the
correct places I'm yet to see a situation where there isn't some useful contextual
information that can and should be added to the message. If there isn't anything
to add, you invariably shouldn't be handling the exceptio
Hi,
On Wed, May 27, 2009 at 11:41 PM, Robert Elliot wrote:
> My logging implementation gives me that information if I want it.
Then why are you using SLF4J?
The main purpose of a logging facade like SLF4J is to cover cases
where you don't and can't know what logging implementation or
configurat
Again, I really appreciate all the suggestions. I'll take a look at
slf4j-simple - it sound like that might be the best way to go rather than
simple class extension.
As for the short circuit code (log.isDebugEnabled()), that becomes much less
of an issue with the slf4j methods like:
public vo
Jukka Zitting wrote:
Hi,
On Wed, May 27, 2009 at 11:41 PM, Robert Elliot wrote:
My logging implementation gives me that information if I want it.
John mentioned that he had several logging systems to contend
with. Moreover, log4j and logback can print the invoking thread's name
whereas j.u
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 configurati
>> My logging implementation gives me that information if I want it.
> Then why are you using SLF4J?
> The main purpose of a logging facade like SLF4J is to cover cases
> where you don't and can't know what logging implementation or
> configuration will be used in places where your code is being
Hi,
On Thu, May 28, 2009 at 4:32 PM, Robert Elliot wrote:
> I take it you include a date stamp in all your log messages then?
Point taken. Though in fact I would put a timestamp in a log message
if it was directly relevant to the logged event ("System time updated
to {}", time). And I've seen pl
Jukka Zitting wrote:
Anyway, what I was trying to say is that you can typically get away
with less detailed log messages when you have access to the source
code (and understand it, e.g. you known how the controller in your
example it works) and detailed logging metadata (thread names, line
num
Jukka Zitting skrev:
Hi,
On Thu, May 28, 2009 at 4:32 PM, Robert Elliot wrote:
I take it you include a date stamp in all your log messages then?
Point taken. Though in fact I would put a timestamp in a log message
if it was directly relevant to the logged event ("System time updated
Hi,
On Thu, May 28, 2009 at 6:17 PM, Ceki Gulcu wrote:
> Are you saying in the majority of SLF4J deployments the thread name is
> not available?
No, just that in most cases some essential piece of the puzzle (source
code, stack traces, or in this specific example thread names) is not
readily ava
http://bugzilla.slf4j.org/show_bug.cgi?id=134
Summary: Allow to set FQCN in Log4jLoggerAdapter class
Product: SLF4J
Version: 1.5.x
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P1
13 matches
Mail list logo
