[logback-user] log4j/logback/JCL/SLF4J???

Ceki Gulcu ceki at qos.ch
Tue Oct 6 15:51:27 CEST 2009

David Vergnaud wrote:


 > My goal is to have logs written in an abstract, language-independent
 > way (level, timestamp, message ID and name/value parameter pairs), so
 > they can be displayed e.g. in different languages (e.g. in a web
 > interface). For this, I want to use XML as the basis format for the
 > logs. Ideally, logs should be rotated, with each finished file being a
 > valid XML document by itself (i.e. with wrapping tag, would've worked
 > in log4j if the writeFooter() method had been called in
 > FileAppender.closeFile() ). It is quite clear to me that the current
 > log file will probably *not* be a proper XML document (no end tag),
 > but I'll take care of that later. I might also consider being happy
 > with having invalid XML log files (no wrapping tag) and including them
 > in a wrapper file using a SYSTEM entity. I'll see.

You could create your own layout (see section "Writing your own layout
in [1]) which could output logging events in XML format. The
getContentType(), getFileHeader(), getFileFooter() methods in your
Layout will be invoked when the log file is opened or closed, so as to
produce valid XML .

[1] http://logback.qos.ch/manual/layouts.html

 > Also ideally, if possible, I'd like to have a system that allows
 > setting the log level on a medium basis -- i.e. have the very same
 > message, from the very same logger, be logged only on channels for
 > which the log level is enabled. For instance, I'd like to be able to
 > use a single logger (in the log4j sense) with one console channel and
 > one file channel, and have the file channel record all levels (debug -
 > error) while the console displays only e.g. info to error. AFAIK this
 > wasn't possible with log4j, as the logging level was defined for each
 > logger, and the logger itself decided for all appenders whether a
 > message should be logged or not.

Both log4j and logback have the capability you are asking for. See the
chapter on filters http://logback.qos.ch/manual/filters.html

 > I don't mind expanding a bit on an existing library, but I'd like most
 > of the functionality I've just described to be readily available or at
 > least foreseen. Does anyone have a good idea?

Before extending logback, I suggest that you spend some time reading the manual.

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

More information about the Logback-user mailing list