On Sat, 6 Oct 2001 20:53, Pratik Patel wrote: > There is a point I would like to bring up sooner rather than later w.r.t > SAR deployment/undeployment and misc data files. > Should we make a separate directory for config & data for SARs? Here's some > reasons:
Thats a long term goal for me ;) The config data should be solely managed by the ConfigurationRepository. In case of the default configuration repository this will probably be good to be stored in another directory somewhere. In case of LDAP this is stored on a directory server somewhere. However I really haven't thought about it long enough at this stage and don't have a lt of time to impliment it. Unless your volunteering to do it ? ;) > * Upgrades: the code may change, but the config file will likely remain the > same between at least minor releases of a bar/sar > * Upgrades: data is not likely to be scrapped between upgrades, it might > even be necessary to keep 'old' data around definetly! I just had to go through the pain of upgrading something the other week and it was painful. > * Upgrades: if the config file FORMAT does change, the bar would be > responsible for migrating old config -> new config Thats an interesting idea. I am not sure where the responsibility for this should lie though. I would prefer to use an XSL sheet to perform upgrades or maybe a separate class that is passed Config tree. So you add something like <config-updater-class>com.biz.MyBlockUpdater</config-updater-class> to your block info. That could be a very very very very good feature. It is something I know quite a few people would like. > * ModifyableConfig: When we eventually implement modifable configs, we need > to have a standard place for reading and writing config files > * Management Console: When we eventually write a managment console it would > make it easier to discover config files which should be accessible for > modification. > > The question as to where this separate dir (if at all) should be located. > I've always bounced between keeping all of the bits of a module together > vs. logically putting bits of a module into neat little buckets. Let me > explain with some examples: I can go either way. For small deployments, keeping all the bits of a module together is superior. However as soon as you start clustering or have large scale deployment it is better to centrally manage these things. A few people in academic environs have requested centralized management a few times. They wanted to centrally manage all things from one place. ie Even if there was 10 different Foo servers round the place there would be one place where configuration is managed. > Logically putting bits of a module into neat little buckets > /avalon/config/BARname/config.xml > /avalon/config/BAR2name/config.xml > /avalon/config/BAR2name/users.xml > /avalon/config/BAR2name/preferences.xml > /avalon/config/server.xml > /avalon/config/assembly.xml > /avalon/data/BARname/bar_data_file.txt > /avalon/data/BAR2name/spool/.... > /avalon/data/BAR2name/users/user1.data > /avalon/common/lib/avalon.jar > /avalon/common/lib/phoenix.jar > /avalon/sar/BARname/BAR.jar > /avalon/sar/BAR2name/BAR2.jar Thats one thing that the EAS people wanted ages. The infrastructure for this sort of thing is about 30% done. I started to write an excalibur.extensions.* that managed repositorys of JDK1.3 style extensions. So you could say that Block foo requires SAX extension compatible with version 2.0 and Phoenix would search in Package Repository and grab out a suitable jar (say xerces or maybe crimson). So when this is done you can store all the .bar and .jar files in a central repository (if they are marked as extensions/Optional Packages). All you have to do is make sure your code requires them using standard Optional Package declarations (see jdk1.3 docs for an example). The rest would require minor changes to the Installer tool. So it is not hard to program this - it is just hard to figure out how to support this. Once we have more fully developed install/uninstall it should be easier to tweak though. Anyways I kinda like the way we do it now for most purposes. -- Cheers, Pete ------------------------------------------------------------ I just got lost in thought... It was unfamiliar territory. ------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
