[xwiki-devs] [Proposal] New configuration strategy
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
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg. -Vincent
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins. Thanks, JV.
On Mar 19, 2010, at 6:54 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's: UC5: Make XWiki work without configuration files. Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default. WDYT? Thanks -Vincent
On Fri, Mar 19, 2010 at 7:03 PM, Vincent Massol <[email protected]> wrote:
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's:
UC5: Make XWiki work without configuration files.
Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default.
for UC5 1/ We put a minimal list of plugins in core code, we don't put config files in the WAR, we add a plugin to XE in the next release, the user will have to update his config file 2/ We keep the default config for XE in the WAR, we add a plugin in the next XE release, the user doesn't have anything to do (if we encourage to only override some settings and not all) I agree your solution is cleaner but imho it's not the most convenient for admins. Also, I think the situation would be different if XE was the platform, in this case we could put XE plugin list in the code. Thanks, JV.
On Fri, Mar 19, 2010 at 19:03, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:54 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's:
UC5: Make XWiki work without configuration files.
Don't mix platform default and XE default configuration values.
Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mar 20, 2010, at 10:33 AM, Thomas Mortagne wrote:
On Fri, Mar 19, 2010 at 19:03, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:54 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's:
UC5: Make XWiki work without configuration files.
Don't mix platform default and XE default configuration values.
Indeed, good point. So yes what I propose for now then is to fallback to WEB-INF/ when not found in steps 1) through 3). What we could though do is not have any config files for platform (and thus use defaults found in the code) but this can be done a bit after. What I'm interested for now is to agree about the system properties, JNDI and the home dir stuff, i.e. steps 1) to 3). Do we have an agreement on that? Thanks -Vincent
Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default.
WDYT?
Thanks -Vincent
On Sat, Mar 20, 2010 at 11:34, Vincent Massol <[email protected]> wrote:
On Mar 20, 2010, at 10:33 AM, Thomas Mortagne wrote:
On Fri, Mar 19, 2010 at 19:03, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:54 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol <[email protected]> wrote: > > 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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's:
UC5: Make XWiki work without configuration files.
Don't mix platform default and XE default configuration values.
Indeed, good point.
So yes what I propose for now then is to fallback to WEB-INF/ when not found in steps 1) through 3).
What we could though do is not have any config files for platform (and thus use defaults found in the code) but this can be done a bit after.
What I'm interested for now is to agree about the system properties, JNDI and the home dir stuff, i.e. steps 1) to 3).
Do we have an agreement on that?
Yep If WEB-INF is 4) it would still be good to have a 5) warning if nothing has been found in 1) to 4) just to make sure the user knows he did not set any configuration file (or he put the files in the wrong place).
Thanks -Vincent
Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default.
WDYT?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 03/19/2010 06:54 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol<[email protected]> wrote:
On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote:
On Fri, Mar 19, 2010 at 6:08 PM, Vincent Massol<[email protected]> wrote:
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
We could keep the config files in the WAR and fallback on them, WDYT ? It would have an interesting side effet, some could only overwrite a couple of config entries in ~/.xwiki/xwiki.cfg and leave the other entries up to the xwiki.cfg bundled with the WAR (which could evolve between releases).
I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.
It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.
The perfect time to get rid of plugins... -- Sergiu Dumitriu http://purl.org/net/sergiu/
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? 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
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
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
On 03/22/2010 09:53 AM, Vincent Massol 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
+1
wdyt?
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?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Another idea (not sure yet how to implement it correctly): * Put the HSQLDB database/ directory in the xwiki config dir (if not specified through system property or JNDI context then the xwiki config dir is the current dir). IMO it makes sense since db is data and it should be easy to upgrade and keep your data too. The pb is in succeeding in defining where to put the hsqldb files but there are ways I think (I can think of some but need more thinking). One solution though is to fold the hibernate config data into the xwiki properties files and configure hibernate programmatically instead of through its XML format. Another option is to combine both: use the Hibernate properties file format and programmatically set the database location if some special token like ${xwiki.config.dir} is used. See http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configura... Side note: these 2 solutions would solve the merging issue with XML file too. WDYT? 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
participants (4)
-
Jean-Vincent Drean -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol