logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <c...@qos.ch>
Subject Re: Verifying initialization
Date Tue, 15 Sep 2009 10:37:18 GMT

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.erskine@ketech.com> wrote:
>>>> From: Jacob Kjome [mailto:hoju@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message