Mark,
You should be right.
The deprecated method
"Category.defaultHierarchy.setDisableOverride(override);"
may not override
"LogManager.getLoggerRepository().setThreshold(XLevel.TRACE); "
Reason I am setting the threshold in the code is that the custom defined
level works from the code but not from the configuration.
Yes that's strange...
Here is the way I am defining the custom Level in the configuration:
<root>
<priority value="TRACE" class="some.package.XLevel"/>
<appender-ref ref="TEMP" />
</root>
<filter class="org.apache.log4j.varia.LevelMatchFilter">
<param name="LevelToMatch" value="TRACE#some.package.XLevel" />
<param name="AcceptOnMatch" value="true" />
</filter>
This above xml elements was given to me by person named Ceki.
I am still waiting for a response from him, on what goes in "LevelToMatch"
within the filter element.
Beacuse I can't match my "TRACE" level to any of the API defined levels like
debug, info...My int value of "TRACE" is greater then "debug" and less than
"info"
Yes plese send me the code extensions for the watchdog. That would be very
helpful.
Thanks for your excellent feed back
-Naveen
-----Original Message-----
From: Mark Womack [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 5:36 PM
To: 'Log4J Users List'
Subject: RE: Runtime Enable/Disable Logging
Navneen,
Looking at the 1.1.3 code, setting the log4j.disableOverride property is the
same as calling this code:
Category.defaultHierarchy.setDisableOverride(override);
Be aware that this method has been deprecated in log4j 1.2beta, and now does
nothing. In fact, the log4j.disableOverride property does not appear to be
used/referenced in the 1.2 version at all. Not sure if it was replaced with
something else.
Here is the relevant documentation from 1.1.3 that you may have already
read:
---
Setting the system property log4j.disableOverride to "true" or any other
value than "false" overrides the effects of all methods
Hierarchy.disable(java.lang.String), Hierarchy.disableAll(),
Hierarchy.disableDebug() and Hierarchy.disableInfo(). Thus, enabling normal
evaluation of logging requests, i.e. according to the Basic Selection Rule.
If both log4j.disableOverride and a log4j.disable options are present, then
log4j.disableOverride as the name indicates overrides any log4j.disable
options.
--
I am not sure it is doing what you expect. Why are you setting the
thresholds in the code?
Also, if you are interested in writing a watchdog for your purposes, let me
know. I can send you the relevant code from the extensions I have worked
on. They are compatible with 1.1.3 and the current 1.2 version.
-Mark
-----Original Message-----
From: Naveen Bathula [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 1:53 PM
To: 'Log4J Users List'
Subject: RE: Runtime Enable/Disable Logging
Mark,
Sorry, I don't have any code that acts as a watchdog on the database.
Within limits of my current framework architecture:
I have to reload the Bean, meaning I have to sync the bean with the database
and that could be done every few seconds/minutes. But I don't yet have this
in place.
My initial question was on how to overide the level at run time without
changing the binary.
I thought the following lines as a possibility. But dosen't seem to work.
java startAppServer -D log4j.disableOverride=true (Gets the level from the
Loaded Config, i.e database)
should ignore the level set in the code
i.e LogManager.getLoggerRepository().setThreshold(XLevel.TRACE);
Thanks
NAveen
-----Original Message-----
From: Mark Womack [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 4:04 PM
To: 'Log4J Users List'
Subject: RE: Runtime Enable/Disable Logging
Navneen,
Is there a way you can query to see if any configuration changes have been
applied to the database?
I ask because I have been working on a "watchdog" design that extends the
configureAndWatch() mechanism. I would be very interested in seeing if a
database version could be written using the current design. I already have
versions that watch a file (like the current code), a web url, and a socket
for new/updated configuration information.
thanks,
-Mark
-----Original Message-----
From: Naveen Bathula [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 12:57 PM
To: 'Log4J Users List'
Subject: RE: Runtime Enable/Disable Logging
Scott,
Apparently I have to read configuration xml file from the database. So any
changes would first have to go in the database. LogReader EntityBean would
then load and cache the config info.
-Naveen
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 3:53 PM
To: Log4J Users List
Subject: Re: Runtime Enable/Disable Logging
Why don't you just use the DOMConfigurator and use the configureAndWatch()
method to initialize log4j. Then you can change the config file dynamically
at
runtime and have it take effect. This is probably the best (& easiest) way
to use
log4j when you want dynamic logging changes at runtime.
-Scott
Naveen Bathula
<nbatula@intel To: Log4J Users List
<[EMAIL PROTECTED]>
idata.com> cc:
Subject: Runtime Enable/Disable
Logging
03/13/2002
11:55 AM
Please respond
to "Log4J
Users List"
I am using log4j-1.2beta3
I set the Logging Level to be "FATAL"
LogManager.getLoggerRepository().setThreshold(XLevel.FATAL);
in the code.
I came across a mailing list where we can overide the Level with out
changing the binary at the client site using the command at run time
java ..... -D log4j.disableOverride=true (I set this during run time)
This Level is set to debug in the configuration
<priority value ="debug" />
<appender-ref ref="CONSOLE"/>
But I don't see all my debug messages....
Am I doing something wrong.....
How can we overide the threshold Level set in the binary code during rin
time?
Thanks
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
