logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Kjome" <h...@visi.com>
Subject Re: Verifying initialization
Date Mon, 14 Sep 2009 19:49:02 GMT
Sounds to me like you're proposing a new Log4j sub-project.  We look forward 
to your contribution, as I'm sure many will find it useful :-)

Jake


On Mon, 14 Sep 2009 12:03:22 -0700 (PDT)
  ecmcn <eric.mcneill@gmail.com> 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
>> 
>> 
>> 
> 
> -- 
> 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
> 
> 


---------------------------------------------------------------------
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