> ... > 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.
This is the exact kind of thing that I ultimately want, except I hope to take it a little further yet. I really am a fan of the Springframework (www.springframework.org). What I want to do is implement a centralized configuration system for an application that can manage that app when deployed on a cluster of J2EE servers. My original thought is to have log4j & Spring safely supporting dynamic reload of configuration from disk. Then implement a few simple component pieces. 1) centralized (SQL) database. The database would be responsible for holding all data, including an audit trail (who changed what, with comments as to why), and history (what was changed, and when). This database would also be the repository for user / groups / roles etc. ultimately used by JAAS. 2) Build some DAO's (preferably using hibernate) to interact with the database and perform persistence logic. Wrap those DAO's and some additional logic behind either a web app (for online access) or preferably behind JMX MBeans. Since everything is behind JMX MBeans everything can be controled by HP openview, or any other JMX remoting compatible system. Have the additional logic support features like rolling back (not database rollback) configurations to a previous state, displaying audit / history trails, enforcing security, verify new config data is in correct format & within correct range, etc.. 3) By implementing a "context", or heirarchy system (think paths, like file system paths, or xpath.... /application/cluster/node/app_server_instance/app_instance/springframework_c ontext/more_springframework_context/setting_to_change ) I can apply changes to one server, or a group of servers, or the entire cluster of servers. So the configuration changes are not an all or nothing situation. This is critical when deploying new code to a cluster, as some machines may have new code and new new configuration settings while other machines are running old code. Also have the ability to "migrate" a configuration from one machine to another. This will help immensly when deploying to a cluster. Setup the first machine, test it. When deploying to other machines, simply "migrate" the configuration (copy it to another context). 4) Send out all configuration modifications via JMS. Have a simple JMS listener app (perhaps a separate app, perhaps part of the applications EAR) pull down the new config, write it to disk and then issue a reload request to Spring and log4j. This app is always brought up first (if possible) so that any new configuration changes are pulled down before the other apps start. The configurations are saved to disk to simplify integration with Spring and log4j, but also so that if the central config system is down and this app needs to be restarted it can use the "cached" version on disk. (assuming of course that no configuration changes are needed to restart the app - but even if they are you can manually update the config file - of course this defeats history & audit but if you have to, you have to.) Thoughts? Later Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
