22 Mar
2010
22 Mar
'10
10:30 a.m.
On Mar 22, 2010, at 10:23 AM, Thomas Mortagne wrote:
On Mon, Mar 22, 2010 at 09:53, Vincent Massol
<vincent(a)massol.net> wrote:
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
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:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs