I've been lurking and have a few thoughts on this thread. I'm currently involved in some projects that are similar to what's being discussed. So, I'd like to chime in with my thoughts on the subject.
Persistence should be an option. I can easily envision loading and saving the log4j configuration data (xml or properties) to/from an external database. Providing a pluggable interface for this would make it someone elses problem to provide a persistence mechanism suitable for their own needs. But, let's go one step further. Let's say that we're administrating a cluster of servers. In some cases, I'd like to make one-off changes to one server only, and not persist them. In other cases, I'd like to make changes that are persisted (to a database) and made effective across the entire cluster. Of course, the persistence mechanism should be abstract, allowing persistence to be done via a filesystem, JNDI, database, etc... And cluster notification should be abstract as well, allowing one to plug-in a JavaGroups, JMS, or smoke signal based implementation. Such a notification mechanism would probably include special 'watcher' implementations to notify the other nodes of a change. So, what could be persisted? XML is more comprehensive than the properties format. So, we'd need to write some code to marshall the configuration graph to Digester compatible xml. Any 'comments' from the original xml would be lost. Even simpler would be to serialize the configuration object tree. But this would not be human readable. That may be okay, however, since it could be 'visualized' via the JMX console. Regards, Tom Drake -----Original Message----- From: Rob Butler [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 1:20 PM To: Log4J Developers List Subject: Re: reload behavior modification / feature request 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
