Tom, a big +1 on everything you've said. IIRC, there are a couple of people who are very interested in this space and are interested in developing these concepts for log4j. Am I correct? It would be good if a working party could be established to push this further.
Perhaps if a group could be established they could be nominated into the log4j-sandbox to develop this concept initially with a view to it being integrated into Log4j fully? I really see this area as a very important aspect to the management of a log4j environment, and I would like to encourage this discussion and development as much as I can. cheers, Paul Smith On Fri, 2004-01-23 at 08:57, Tom Drake wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
