On 05/25/2012 12:56 PM, Vincent Massol wrote:
On May 25, 2012, at 3:38 PM, Sergiu Dumitriu wrote:
On 05/25/2012 05:21 AM, Denis Gervalle wrote:
On Thu, May 24, 2012 at 7:23 PM, Vincent Massol<[email protected]> wrote:
On May 24, 2012, at 9:09 AM, Denis Gervalle wrote:
On Tue, May 22, 2012 at 4:03 PM, Vincent Massol<[email protected]>
wrote:
On May 22, 2012, at 3:51 PM, Sergiu Dumitriu wrote:
On 05/22/2012 08:59 AM, Vincent Massol wrote:
On May 22, 2012, at 2:49 PM, Vincent Massol wrote:
Hi devs,
I need to be able to configuration the location of the HSQLDB
database/ directory in our installer when executing on windows7
(because on
windows7 you cannot write to the ProgramFiles directory).
I'm proposing to add variable substitution so that we can configure
connectio.url for HSQLDB to point to the environment.permanentDirectory
location.
We would have:
<property
name="connection.url">jdbc:hsqldb:file:${environment.permanentDirectory)/database/xwiki_db;shutdown=true</property>
Technical details:
* I'll modify DBCPConnectionProvider. More specifically this part:
String jdbcUrl = System.getProperty(Environment.URL);
if (jdbcUrl == null) {
jdbcUrl = props.getProperty(Environment.URL);
}
dbcpProperties.put("url", jdbcUrl);
* And look for ${…} , extract the variable name and use the
XWikiPropertiesConfigurationSource to get the value for that variable
name,
as a String.
WDYT?
Note that another solution to this is to move all Hibernate
configuration data to xwiki.properties… Since we allow property
referencing
in our xwiki.properties file it would solve my need too.
It's a lot more more work though (unless we support both, looking
first
in xwiki.properties for hibernate properties and fallbacking to older
hibernate.cfg.xml if not found, in which case it's a little less work
but
still substantial). I'm still unsure I'm prepared to work on this now…
:)
WDYT?
I don't like this that much, since there's a lot more that can be
configured in the xml file, and the .properties is already getting very
big.
If we really think that the size of the file is important (which I'm not
sure about) then we have the option of having as many configuration
files
as possible by using a CompositeConfiguration.
I agree with Sergiu, but this is not a question of file size. Duplicating
the work done for hibernate configuration is not good, we would both
limit
the flexibility since duplicating the whole possibilities would be hard,
No it wouldn't ;-)
We would automatically take all props starting with storage.hibernate.*
and pass them.
hibernate.cfg.xml is not just a simple list of properties. Are we talking
about the same thing ?
My point exactly. Here's the structure of the XML file:
view-source:http://www.jboss.org/dtd/hibernate/hibernate-configuration-3.0.dtd
It's not just a flat session-factory with a list of property and mapping tags.
We don't know how more advanced installations use this file, and maybe we'll
learn more about using Hibernate the right way, and we'll need to add other
elements: listeners, security, caches…
Guys you really need to read the link I gave you about commons-configuration ;)
commons-configuration supports nested properties whether they are stored in
xml, in properties files or elsewhere.
This isn't about how much or little commons-configuration can do, but
about the fact that hibernate configuration is done in its XML
configuration file in any other project. and changing that, although it
would be better for us, it's going to make it harder for sysadmins to
properly configure their connection when only we know where and how the
configuration works.
and also confuse those who already knows the syntax of such file. So, I
like more the variable substitution proposal. With that one, we could
provide a simplified configuration in our ConfigurationSource, while
keeping the possibility of configuring the XML file directly. This is the
best of both worlds IMO.
As I replied to sergiu there's also a 3rd solution: using a different file
but with commons configuration.
Not sure to understand what you means. All I say is that the
hibernate.cfg.xml is a well-known configuration file, and that it is nice
to be able to use it directly. This is why I prefer variable substitution
in that file, taking any properties from our environment.
Exactly. Most of our users don't have to do much to configure their wiki for a
different database, but if they do need to do some tweaking, all the search
results will point to XML snippets, not to xwiki.properties. We try to stick to
standards, why create our own here?
We already have a standard for xwiki configuration and it's called
xwiki-configuration, that's why ;)
Having 10 places to configure xwiki is not exactly the simplest either…
OK then, so you're proposing to also move components.txt,
struts-config.xml, fop-config.xml, xhtml2fo.xsl, log4j.properties and
logback.xml into xwiki.properties, so that any library we're using
should be configured in the same place, right?
When everyone that knows how to configure these generic libraries in any
other project, isn't it going to be a surprise when logback.xml
suddently doesn't work? Searching for "how do I enable debug logging in
log4j" isn't going to lead to "simple, edit xwiki.properties and bla
bla", but to "edit logback.xml and bla bla". Similarly, when searching
for "how do I increase the pool size for hibernate" is going to lead to
"use this XML snippet in hibernate.cfg.xml". Discovering that
hibernate.cfg.xml doesn't exist but those setting must be placed in
xwiki.properties, and how that XML snippet translates into properties is
going to take some time... One thing I learned? Nobody reads
documentation unless they really have to, and they don't always read the
official documentation that they should read, but instead end up on
forums and blog posts.
Sure, our xwiki.properties file is much simpler to understand, but
that's not what any other human being on earth is expecting.
Anyway to summarize:
1) I'm not pushing too strongly for merging configuration in our file
2) However it could be nice to be able to use xwiki-configuration for all
configuration data since this allows to access the full config from anywhere in
our code using ConfigurationSource and have links between them by using
variables (just to cite 2 features).
Hibernate is not part of XWiki, it's a bridge between XWiki and the
database.
AFAICS 2) is supported by commons-configuration and of course it would require
some tweaks to our configuration API since it currently offers a minimal API
and is far from offering what is supported by apache commons configuration.
For the time being I'll go with adding code to support variable substitution
and if I get the time I'll investigate a bit more to see how we could use
apache commons configuration while keeping separate config files (including
keeping the native format).
Thanks
-Vincent
Thanks
Vincent
The important point here is not so much to have hibernate config in the
same file but rather to have it under our ConfigurationSource mechanism.
Thanks
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
