logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ecmcn <eric.mcne...@gmail.com>
Subject Re: Verifying initialization
Date Mon, 14 Sep 2009 19:03:22 GMT

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.


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
>>have one or more flags set that will indicate the problem in any
>>GUIs, JConsoles, status reports, what-have-you. rather than find out after
>>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

View this message in context: http://www.nabble.com/Verifying-initialization-tp25392804p25440695.html
Sent from the Log4j - Users mailing list archive at Nabble.com.

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message