.properties files and lists of properties.

[Edward Kenworthy]

My application allows the user to manipulate a database. It also allows them to switch between databases at run time.

Currently the available databases are "hard coded" into my beans.xml file.

This has two consequences: if I want to add or remove a datasource I have to add/remove a DataSource entry, add/remove a hibernate session factory, add/remove an action configured with the session factory and add/remove an entry to those beans that keep lists of the available actions (in this case a menu).

Is there anyway I can:

a) externalise the url for the datasources into, say, a separate properties file so it's easier (but not too easy!) to edit once the application has been deployed. (The names of the various testing and staging databases change regularly). Clarification: the bit I don't know is: how do I do this without programmatically loading the .properties file? I'd like to be able to say something like <import properties_file="dataSources.properties"/>. After all what business if it of my application code how I've chosen to structure my beans.xml file?

b) define a list of datasources and have everything else automagically configure itself. (Part of the repetition issue: all the session factories identical apart form the datasource for example, would be addressed by a solution to a).

Edward

[Edward Kenworthy]

Thankyou all for being my cardboard analyst ;-)

<bean id="propertyConfigurer"
class="org.springframework.beans.factory.
config.PropertyPlaceholderConfigurer">
<property name="location"><value>/WEB-INF/jdbc.properties</value></property>
</bean>

[Edward Kenworthy]

Ok so I spoke too soon.

Spring seems to be silently ignoring my propertyConfigurer (it doesn't matter what file name I set it doesn't complain and my ${} don't get replaced) which you'd kind of expect given that it's not referenced anywhere. But then according to the articles I've read isn't propertyConfigurer supposed to be automaigcally isntantiated by Spring?

Edward

[Edward Kenworthy]

It's astonishing. I spent the weekend struggling with this but as soon as I start to articulate the problem the solutions just seem to just magically appear.

This time it's: use ClassPathXmlApplicationContext (which automagically does the necessary fixing up) instead of XMLBeanFactory, which doesn't.