Hi, > > As to the jmx implementation, I'm not sure if overwriting the initial > log4j configuration file is the adequate approach. Or in other words, I > would prefer to not make jmx-manipulations persistent. In our opinion, a > restarted application e.g. should use the originally defined log4j > configuration file instead of a possibly temp. log4j jmx-defined setup > used, e.g., before a crash of the application. What do you think? > Depends on your intended purposes. JMX is a "management" api (and with JMX remoting now a standardized protocol too). To me that means when you make a change, the change is persistent until changed again. If you use JMX to add and run a new EAR on a running J2EE server I would expect that EAR to start the next time I shutdown and restarted the entire app server. If I only wanted a change in logging to be temporary I would expect to make the change - do what I needed to do with the new logging data - and then change it back again. If the application were not restarted the logging modification would stay in place until I changed it again, why shouldn't it do the same thing even if I restart the app. In my opinion the problem with most JMX enabled apps is the modifications are not permanent across restarts.
Also, developers are not necessarily always aware of an application being restarted. Where I work we pretty much have a complete hands off policy for our production J2EE applications - we aren't allowed to login, etc. However, we would be allowed to do something like increase the logging level via JMX, or a web console. I may do this because I need to gather additional data over a long period to track down some minor bug. Should production support need to down the box to work on hardware or some other un-related issue on the box I would be pretty upset to find out that my much needed log data was not collected because the logging change I made via JMX was "reset" when the box was re-started. I don't know of many places that ask a developer if it's ok to bring down a production box to fix hardware, or software un-related to their app. They have policies / procedures, etc. to do all that kind of stuff, but generally the development team is not consulted. Later Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
