Hello,
Logback does exactly what you are asking for. It allows access to its
internal state via the StatusManager. Many of the unit tests in
logback verify the internal state. See
http://logback.qos.ch/manual/configuration.html#viewingStatusMessages
for documentation.
HTH,
ecmcn wrote:
Michael's exactly right about this one. We dynamically create the log4j
config file each time on startup, so that we can change things like the JDBC
database name or JMS message queue as our user config changes. We try to
catch invalid syntax and such before writing the XML but occasionally we'll
hit a case that will cause the XML to fail to load or an appender to fail to
connect to whatever it needs to.
Debug prints to stdout are great for development but they don't do anything
for us in the field. Programmatic verification of startup and occasional
monitoring (or callbacks if something stops working) are really the only
good options I can think of unless logging is just a "nice to have" and
isn't a critical subsystem.
Eric
Jacob Kjome wrote:
On Mon, 14 Sep 2009 08:55:14 +0100
Michael Erskine <michael.ersk...@ketech.com> wrote:
From: Jacob Kjome [mailto:h...@visi.com]
Subject: Re: Verifying initialization
have you tried using?.....
-Dlog4j.debug=true
I think what is being discussed here (correct me if I'm wrong) is the
_unattended_ programmatic verification of initialisation rather than a
one-time human-observed verification or additional verbosity (that nobody
will read anyway!). If the logging isn't working as expected then I
usually
have one or more flags set that will indicate the problem in any
dashboards,
GUIs, JConsoles, status reports, what-have-you. rather than find out after
30
days of uptime that there's no audit trail!
I understand what is desired. And it would certainly be possible to write
such a thing. However, I think it is overkill. Your config file is
either
valid or not. If you run it once with -Dlog4j.debug=true and don't find
any
issues, then, in my book, you are about 99% sure that everything is good
to
go. And reloading the same unmodified configuration at a later date in a
new
JVM should not change that fact. Again, it's either right or it's not.
That
is unless Log4j was embedded with a super-secret randomizer just to mess
with
your head? Thankfully, given the number of eyes on the codebase over the
years, I am fairly certain this is not the case.
So, no, there is nothing to validate runtime configuration. However, the
reason none exists is probably because it's not needed 99.999999999% of
the
time and one-time human validation using -Dlog4j.debug=true is enough for
most
people. If it worked once, it ought to work again.
Jake
Regards,
Michael Erskine.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
