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

[Vincent Massol]

Ok, I missed 2 important points in the proposal below:

1) where do we put the required JARs for both the JDBC drivers and  
for the plugins?
2) do we want to benefit from app server features like clustering, etc.?

For 1), one option would be to create a lib/ directory in the xwiki  
configuration directory and inside XWiki use a URLClassloader that  
inherits from the webapp classloader (or the context classloader) and  
adds this lib/ directory to the mix.

For 2), that's a bigger issue. If we want to benefit from all app  
server features like session persistence, transparent clustering, etc  
we need to abide by the container rules I think. I'm not sure but I  
think we might have an issue by doing our own file access/io to an  
"external" directory. That said this is what JIRA does for example so  
we might want to check this out. I think the official J2EE solution  
is to store the configuration into JNDI. That won't solve issue 1) I  
think.

I'd like your input please. It's possible that point 2) isn't an  
issue in practice.

I still believe it would be neat to have a common WAR and separate  
configurations. Hmm.... An another option would be to package the  
configuration into a zip/jar and have the user expand it over the  
xwiki WAR. This should cater for issues 1) and 2) above. However it  
doesn't solve the easy upgrade (see point 2) below in my original  
mail) but maybe that's a lesser problem.

Of course that last solution is to provide already made WARs for  
specific configurations but that's harder in the build (but doable -  
I have been able to implement this in the m2 build). Maybe this  
combined with the configuration wizard would be good enough? It's  
still less good I think than if were able to release separately the  
WAR from the configuration.

WDYT?

Thanks
-Vincent

On Apr 19, 2007, at 11:52 PM, Vincent Massol wrote:

> 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