20 Apr
2007
20 Apr
'07
9:19 a.m.
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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws