[xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
Ludovic Dubost
ludovic at xwiki.com
Fri Apr 20 22:51:19 CEST 2007
The main reason we haven't even used this ourselves is that it requires
creating a configuration file in the app server (tomcat/conf/ for tomcat)
And in the end it's actually easier to keep a backup of xwiki.cfg
hibernate.cfg.xml and other files needed and overwrite them when
upgrading the war file.
This is true for tomcat since it explodes war files by default and you
can upgrade files by copying.
This is more complex in other app servers especially those that don't
even explode the war file.
I'm not sure there is a current benefit of doing things differently.
So I believe we should properly document how to keep config files
separate but I don't think we should push our tomcat users to actually
use that feature since it does not provide administration benefits.
Or maybe I'm missing a benefit ?
Ludovic
Vincent Massol a écrit :
> If it's already possible then cool. Right now I'm more interested in
> having a default configuration strategy that we all agree on, use
> ourselves in our distributions and document.
>
> Thanks
> -Vincent
>
> On Apr 20, 2007, at 1:33 AM, Ludovic Dubost wrote:
>
>>
>> This is already possible with a variable telling where to find xwiki.cfg
>> From there you can specify where to find the hibernate file
>> From there you can specify where to find the hbm files (however I
>> think these have to be in the classpath)
>>
>> See this code in XWiki.java
>>
>> private static String getConfigPath() throws NamingException
>> {
>> if (configPath == null) {
>> try {
>> Context envContext = (Context) new
>> InitialContext().lookup("java:comp/env");
>> configPath = (String) envContext.lookup(CFG_ENV_NAME);
>> } catch (Exception e) {
>> // Allow a config path from WEB-INF
>> if (log.isInfoEnabled())
>> log
>> .info("xwiki.cfg taken from /WEB-INF/xwiki.cfg
>> because the XWikiConfig variable is not set in the context");
>> configPath = "/WEB-INF/xwiki.cfg";
>> }
>>
>> }
>> return configPath;
>> }
>>
>>
>> Ludovic
>>
>> Vincent Massol a écrit :
>>> Hi,
>>>
>>> For XWiki 1.1 I'd like to separate XWiki's configuration files from
>>> the generated WAR.
>>>
>>> What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
>>> xwiki.hbm, feeds.hbm and possibly some others.
>>>
>>> Rationale:
>>>
>>> 1) It would be nice to release different already made configurations
>>> for XWiki: for HSQLDB, for MySQL, for Oracle, with a minimal list of
>>> plugins configured, with all plugins enabled, with virtual wiki set
>>> up, etc. It's going to be way better to release a single WAR that is
>>> the same for all configs and a set of config files separately. This
>>> also makes it much easier in the build process.
>>>
>>> 2) It's currently a little bit of a pain for users when they upgrade
>>> their xwiki installation to a newer version. They have to remember
>>> to save their config files, to unpack the XWiki WAR, modify the
>>> configuration files, etc. What if an upgrade was a simple as
>>> dropping the new WAR file in the webapps/ directory of your servlet
>>> container? :)
>>>
>>> Thus I'd like to propose the following strategy:
>>>
>>> * XWiki looks for where the config files are stored using the
>>> following algorithm:
>>> 1) first it checks if a system property has been defined (say for
>>> example "xwiki.configuration.directory")
>>> 1) if not, it checks if a location has been specified in the
>>> web.xml file (as an init parameter)
>>> 2) if not found, it checks if the files can be found at the root
>>> of the classpath (e.g. "/xwiki.cfg")
>>> * The standalone distribution contains an already configured
>>> directory structure which uses the system property strategy for
>>> finding the configuration directory.
>>>
>>> <further future - but not too far as it's the best solution I think>
>>> We should propose a configuration wizard application which is in
>>> charge of generating xwiki configuration files. I propose the
>>> following distribution channels:
>>>
>>> - as a webapp wizard configured on xwiki.org. Users use forms to
>>> select what they want (which plugin, virtual wiki or not, etc). It
>>> generate the files that can be downloaded by the users. Actually
>>> this can even be implemented as a XWiki Application... ;-) Eating
>>> our dog food they said...
>>>
>>> - as a webapp wizard released inside the default WAR and that is
>>> activated automatically if no configuration is found, i.e. the first
>>> time XWiki is started. This is really by far the best I believe.
>>>
>>> </further future>
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the
>>> xwiki-dev at objectweb.org mailing list.
>>> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
>>> For general help: mailto:sympa at objectweb.org?subject=help
>>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>>
>>
>>
>> --Ludovic Dubost
>> Blog: http://www.ludovic.org/blog/
>> XWiki: http://www.xwiki.com
>> Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
>>
>>
>>
>> --
>> You receive this message as a subscriber of the
>> xwiki-dev at objectweb.org mailing list.
>> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
>> For general help: mailto:sympa at objectweb.org?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the xwiki-dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
More information about the devs
mailing list