logging from jar file
In our application, we don't user a log4j.properties, we configure the logger in the code using this: PropertyConfigurator.configure(getProperties()); If we do that, and then use Apache Axis (which uses commons-logging), will it pick up the same configuration? If not, would Axis's commons-logging try to find a log4j.properties on it's own? Thanks in advance. Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
I don't know if this would work but you could try recursing the logger tree removing all appenders and reseting all levels before calling configure. On 2/16/07, zeusfaber <[EMAIL PROTECTED]> wrote: James Stauffer wrote: > > For one thing, DOMConfigurator.configure adds to the current config -- > it doesn't replace it. Thay is why some loggers still see the changed > configuration. > Thank you James for you prompt reply. Hummm, this could be the reason I'm seeing strange behaviours. But so, what would be the correct procedure to reload programmatically the old configuration without restarting the application? I found no evidence in the complete manual too :-) bye -- Davide -- View this message in context: http://www.nabble.com/Changing---Retrieving-log4j-config-at-runtime-tf3238396.html#a9007011 Sent from the Log4j - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Staufferhttp://www.geocities.com/stauffer_james/ Are you good? Take the test at http://www.livingwaters.com/good/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
Curt Arnold wrote: > > A null return from Logger.getLevel() indicates that logger does not > have an explicit level, but inherits a level from its parent or their > parents. If you return the parent's level in this situation, you can > no longer distinguish between a logger who has a level of its own and > should not be affected by a change of its parent's level and a logger > which has no level of its own and should be affected by a change of > its parent's level. > It was the only solution I found to solve it. Actually in my log4j.xml this loggers are defined as: So all my levels are explicit. Bye -- Davide -- View this message in context: http://www.nabble.com/Changing---Retrieving-log4j-config-at-runtime-tf3238396.html#a9007161 Sent from the Log4j - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
James Stauffer wrote: > > For one thing, DOMConfigurator.configure adds to the current config -- > it doesn't replace it. Thay is why some loggers still see the changed > configuration. > Thank you James for you prompt reply. Hummm, this could be the reason I'm seeing strange behaviours. But so, what would be the correct procedure to reload programmatically the old configuration without restarting the application? I found no evidence in the complete manual too :-) bye -- Davide -- View this message in context: http://www.nabble.com/Changing---Retrieving-log4j-config-at-runtime-tf3238396.html#a9007011 Sent from the Log4j - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
On Feb 16, 2007, at 9:43 AM, zeusfaber wrote: Any idea where I'm wrong? Thank you in advance -- Davide A null return from Logger.getLevel() indicates that logger does not have an explicit level, but inherits a level from its parent or their parents. If you return the parent's level in this situation, you can no longer distinguish between a logger who has a level of its own and should not be affected by a change of its parent's level and a logger which has no level of its own and should be affected by a change of its parent's level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
For one thing, DOMConfigurator.configure adds to the current config --
it doesn't replace it. Thay is why some loggers still see the changed
configuration.
On 2/16/07, zeusfaber <[EMAIL PROTECTED]> wrote:
Maybe this is the correct thread ;-)
In my application I'm changing and retrieving programmatically logger levels
via the:
logger.setLevel(...) /getLevel()
Then I though to add a "restore defaults" feature that reloads the original
configuration through:
DOMConfigurator.configure(xmlFilePath);
Now I' m having problems becouse, *sometimes* *some* loggers still see the
changed configuration.
Sometimes the logger.getLevel() reutrn null so I added a check:
Level level = loggerInstance.getLevel();
if (level == null)
{
Logger root = Logger.getRootLogger();
return root.getLevel().toInt();
}
return level.toInt();
Any idea where I'm wrong?
Thank you in advance
--
Davide
--
View this message in context:
http://www.nabble.com/Changing---Retrieving-log4j-config-at-runtime-tf3238396.html#a9006677
Sent from the Log4j - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
James Staufferhttp://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
Maybe this is the correct thread ;-)
In my application I'm changing and retrieving programmatically logger levels
via the:
logger.setLevel(...) /getLevel()
Then I though to add a "restore defaults" feature that reloads the original
configuration through:
DOMConfigurator.configure(xmlFilePath);
Now I' m having problems becouse, *sometimes* *some* loggers still see the
changed configuration.
Sometimes the logger.getLevel() reutrn null so I added a check:
Level level = loggerInstance.getLevel();
if (level == null)
{
Logger root = Logger.getRootLogger();
return root.getLevel().toInt();
}
return level.toInt();
Any idea where I'm wrong?
Thank you in advance
--
Davide
--
View this message in context:
http://www.nabble.com/Changing---Retrieving-log4j-config-at-runtime-tf3238396.html#a9006677
Sent from the Log4j - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing / Retrieving log4j config at runtime
Look for LogWeb it is a servlet that allows configuring log4j. It will either meet your needs or show you how to do what you want to do. On 2/16/07, Gaurav Arora <[EMAIL PROTECTED]> wrote: Hi, I have been trying to retrieve all loggers attached to a root log using a servlet that runs at server startup but I haven't been able to do so yet. I tried using the getAllAppenders method, which the manual says is deprecated and the Hierarchy class as well, both don't seem to work. What I am trying to do is, get a list of all loggers and appenders attached to them on server startup and dump them in a more user friendly view. Have I been doing it the wrong way? Is there a better way to do the above? I'm using version 1.2.14 and Tomcat 5.5. Thanks, Gaurav Disclaimer :- This e-mail message including any attachment may contain confidential, proprietary or legally privileged information. It should not be used by who is not the original intended recipient. If you have erroneously received this message, you are notified that you are strictly prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sender. Newgen Software Technologies Ltd and / or its subsidiary Companies accept no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Newgen Software Technologies Ltd and / or its subsidiary Companies, as applicable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Staufferhttp://www.geocities.com/stauffer_james/ Are you good? Take the test at http://www.livingwaters.com/good/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing / Retrieving log4j config at runtime
Hi, I have been trying to retrieve all loggers attached to a root log using a servlet that runs at server startup but I haven't been able to do so yet. I tried using the getAllAppenders method, which the manual says is deprecated and the Hierarchy class as well, both don't seem to work. What I am trying to do is, get a list of all loggers and appenders attached to them on server startup and dump them in a more user friendly view. Have I been doing it the wrong way? Is there a better way to do the above? I'm using version 1.2.14 and Tomcat 5.5. Thanks, Gaurav Disclaimer :- This e-mail message including any attachment may contain confidential, proprietary or legally privileged information. It should not be used by who is not the original intended recipient. If you have erroneously received this message, you are notified that you are strictly prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sender. Newgen Software Technologies Ltd and / or its subsidiary Companies accept no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Newgen Software Technologies Ltd and / or its subsidiary Companies, as applicable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
