Hi Sergiu, On May 26, 2012, at 7:16 PM, Sergiu Dumitriu wrote:
> 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. Maybe you're not aware of the capability of commons-configuration; you can have the config data in any format, including XML and you can have a Composite Configuration which loads several config data in different formats (properties, xml, database, etc). I haven't checked recently but it was supporting all that when I introduced the xwiki-configuration module so I guess this is still the case. >>>>>> 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. Again i'm not pushing too much for this. But what I'd like is to have all those files located in the same configuration data directory. I had assumed we wanted to have the environment.permanentDirectory be that directory but Denis suggested to have 2 different directories which is kind of ok (I need to think more about this - BTW Denis commons-configuration allows modifying the configuration files so we also have the ability - should we want it - to write into configuration files). > 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. All that I care is that XWiki users need to configuration hibernate configuration data. Whether it belongs to XWiki or not is a philosophical topic that doesn't interest me that much ATM ;) Sergiu I don't disagree with what you're saying. Again what's important to me is first and foremost to group configuration files together (same for permanent data we output). Having them under commons-configuration is just a nice to have since it allows to benefit from a lot of features (including ability to share variables AFAIU). We can check later and more precisely if we can have the best of both worlds (don't have much time for that anyway). BTW I don't consider components.xml to be a configuration file. It's not modifiable by the user. Thanks -Vincent >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
