On Mar 22, 2010, at 10:23 AM, Thomas Mortagne wrote: > 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.
I don't think so. For me there are only 2 levels: - default values - overridden values The location of overridden files is an exclusive OR. Otherwise you'll get issues, especially for UC3 and UC4. Thanks -Vincent >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
