> Cool - I applied most of it except for uninstallation part. The reason was > that we don't want uninstallation to delete whole tree because apps may be > storing data in there (ie james stores it's mail spool there). I just issued > an error message for the time being.
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: * 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 * Upgrades: if the config file FORMAT does change, the bar would be responsible for migrating old config -> new config * 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: What was proposed in another email, or keeping all of the bits of a module together >>SAR-INF/lib/myBlockArchive.jar >>SAR-INF/lib/mySupport.jar >>SAR-INF/server.xml >>SAR-INF/config.xml >>SAR-INF/assembly.xml >>SAR-INF/data/my-random-datafile.txt (I've prepended SAR-INF to this one) (not exactly like this, but something similar) 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 I prefer keeping everything together (first example above) but what got me thinking about this was the management of these components: upgrading sars/bars, adding/removing config params, handling data between server restarts/code updates. The other thought was partitioning the data from the everything else: if we have a mail spool or some other data directory, we would ideally want to be able to keep an eye on it and even keep it on a separate filesystem(?) in case it starts to grow quickly. Of course, option two requires alot of work to unpack a bar/sar properly, and it is messy. The danger in keeping everything together is that its too easy to think of SAR-INF (or whatever we call it) as disposable rather than something that should be persistant. cheers Pratik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
