On Mon, Mar 22, 2010 at 09:53, Vincent Massol <[email protected]> wrote: > Hi, > > I'd like to propose a small variation which is to consider WEB-INF/* > properties as default values and all the other location are overrides. > > Thus to summarize: > > Use Cases: > > UC1: Easy install: no need to explode the XAR to install XWiki. See also the > comment about xwiki on http://java.dzone.com/articles/file-system-storage-and > UC2: Easy upgrade: no need to take care about saving the configuration so > that it's not overwritten by an upgrade > UC3: Should be possible to have multiple installs on the same machine and > running at the same time > UC4: Should be possible to control the location of the configuration files > for our automated functional tests (so that we control the configuration used) > UC5: Make XWiki work without configuration files > > Implementation: > > 0) Read the default properties from xwiki.cfg and xwiki.properties and the > steps below (1) to 4)) will override these default values, so that users only > need to define properties they want to override. Note that ideally we would > do the same with hibernate.cfg.xml but it's harder to implement since it > means merging an XML file. > 1) Look for a system property (e.g. xwiki.config.dir) defining a directory > location and if defined look for the files in it using File IO (I know it's > not JEE kosher but it's acceptable IMO, especially since it won't break and > we'll fallback in case of problem). Could be relative or absolute. > 2) If not found, look for a JNDI property that gives the location of the > config directory > 3) If not found, look for config files in [user.home]/.xwiki > > wdyt?
+1 for the merging idea but we should maybe apply it for each level: fill a Properties object with xwiki.cfg, then put properties from xwiki.config.dir/xwiki.cfg, etc... instead of stopping at the first one found. > > Thanks > -Vincent > > On Mar 19, 2010, at 6:08 PM, Vincent Massol wrote: > >> Hi devs, >> >> I've been wanting to make it easy to upgrade XWiki from one version to >> another for some time (I'm not talking about XAR upgrade here, that's the >> extension manager). I'm talking about XWiki configuration files. >> >> Here are the use cases I'd like to solve: >> >> UC1: Easy install: no need to explode the XAR to install XWiki. See also the >> comment about xwiki on http://java.dzone.com/articles/file-system-storage-and >> UC2: Easy upgrade: no need to take care about saving the configuration so >> that it's not overwritten by an upgrade >> UC3: Should be possible to have multiple installs on the same machine and >> running at the same time >> UC4: Should be possible to control the location of the configuration files >> for our automated functional tests (so that we control the configuration >> used) >> >> The configuration files I'm talking about are: >> * xwiki.cfg >> * hibernate.cfg.xml >> * xwiki.properties >> >> Proposed Solution: >> =============== >> >> 1) Look for a system property (e.g. xwiki.config.dir) defining a directory >> location and if defined look for the files in it using File IO (I know it's >> not JEE kosher but it's acceptable IMO). Could be relative or absolute. >> 2) If not found, look for a JNDI property that gives the location of the >> config directory >> 3) If not found, look for config files in [user.home]/.xwiki >> 4) If not found, emit an error explaining how to configure xwiki >> >> 1) solves UC3 and UC4 >> 2) solves UC3 >> 3) solves UC1 and UC2 >> >> Note >> ==== >> >> I'm not suggesting any backward compatibility here since it's a new way of >> configuring XWiki. It means upgraders will need to read the release >> notes/doc to understand how to configure XWiki. >> >> If really needed, we could devise a backward compat strategy, but I'm not >> sure we absolutely need that. >> >> WDYT? >> >> Thanks >> -Vincent >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
