This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Change to Log Levels dynamically via JMX

Aug 11th, 2006, 12:40 PM

Hi,

I have a requirement where in I have to change the log levels dynamically at runtime. It is not possible for me to modify the log4j.properties or log4j.xml as my application is deployed as an .ear file.
I am sure there could be some solution for this, I was thinking of JMX but not sure how. I appreciate if anyone help me in this regard and if possible explain with sample code.

c. then I tried to run the applicaton in weblogic 9.1 by using following java system property
Dcom.sun.management.jmxremote

d. Ran JConsole to view mbeans and was able to see my applogging bean with all the methods but when I try to invoke them it has no impact on log levels of application. Still I see application reacts the way it is defined in log4j.xml file.

Is this approach correct, if yes what is that I am missing here, Can we totally eliminate the need of log4j.xml.
Do we need to pass anything for target parameter in the method of your example from jmx console.

Depends on your application server JMX implementation - if the calls are spread across the rest of the JMX servers, then yes.
Check your cluster configuration - note that with JMX one can create hierarchical servers (for example using jManage).

Comment

we have our application deployed on weblogic 9.1 on three nodes in a cluster and we are trying to achieve dynamic changes to log levels during runtime with no code or property file changes. In this scenario I was trying to understand whether this approach (JMX implementation for log4j) works with impact.

The JMX specs do not cover clustering or federation (grouping a set of JMX servers into one group so calls on the group are propagated to each individual server which in turn, can have other sub groups). This feature along with others are covered, AFAIK, by the next JMX iteration.
That's why, at the moment, you'll have to rely on other tools or libraries to provide this functionality for you.