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


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

View raw message