[xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR

[Ludovic Dubost]

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