Sorry for the noise!
I plugged nlog4j into my app and will stick to it.
Works most of the time.
(Not always with maven-cobertura-plugin 1.1, since that expects
a log4j 1.2.8 or .9, stumbling over the Logger.debug(String)
signature).
Should have read the devel messages before...
On Sun, 2005-05-01 at 21:53 +0100, robert burrell donkin wrote:
[ ... ]
> configuration is the most commonly requested feature for JCL. but
> implementing it would cross an important line leading to an endless
> battle against code bloat and feature drift. explicitly excluded this
> possibility in the proposal was definitely the right approach.
[ ... ]
Though the questions remain:
1. Is there a way to configure an overall log level for the logging
framework sitting under the slf4j API?
Or:
2. Is there a way to figure out which slf4j-Implementation I'm using
at runtime? That way I can implement the switch of level on my own.
Regards,
Heiner
Heiner Westphal wrote:
Hi there!
I just switched a project to slf4j (from apache-commons-logging)
and it was quite easy having "perl -pi" and eclipse 3.1 to aid.
BUT: I would like to have a way to configure the log level,
preferrably of the root logger, without having to know up front,
which logging implementation will be used.
This problem existed with commons-logging as well, IIRC.
Do you plan to add something like Logger.setLevel?
Or is there a way to know, which loggering framework is
in use at runtime?
Maybe I'm approaching the solution of my problem the wrong way
round, so I'll better explain it:
We got an application, which can be run stand alone or from an
eclipse-plugin which optionaly delivers a log file in a format
suitable for display in the eclipse TPTP LogView
(http://www.eclipse.org/tptp/).
The easiest way to get to that format seems to be using java1.4
logging with an adapter/formatter emitting CommonBaseEvent XML.
The log4j-formatter provided by tptp-4.0.0 is too generic, to
be useful and I try to avoid implementing a new one from scratch.
Now I switched to slf4j to use the java1.4 logging framework, whith
minimal changes to the logging api we already used, which had
been commons-logging, until we got into the well known class loader
nightmare (just imagine eclipse plugins using hivemind to access their
respective plugins - outcome depends on order of initialization, ...).
Said application allows you to specify a log level to control the amount
and granularity of output.
Now I would like to allow the deployer to choose the logging framework
used while the application should still be able to change verbosity
programatically.
Any hint, how to accomplish this?
Thanks in advance,
Heiner
_______________________________________________
user mailing list
[email protected]
http://slf4j.org/mailman/listinfo/user
