More flexible Spring context.xml configuration

[bclozel]

I've been chatting with RESThub users and developers. I'm wondering if some contexts/properties should be moved to projects archetypes.

Use case: One team wants to integrate Hibernate Search in their project. They had to override the datasource bean definition to add properties related to search.

Should we:

• promote (partial) bean definition override and collection merging
• move those some of those in projects archetypes to let developers handle what they want

Moving those is a good thing on the "promote best practices front", but could be a problem for future RESThub migrations...

Discuss!

[sdeleuze]

I had quite a lot of discussion with developers before going to vacations. I think moving applicationContext.xml to archetypes would be great in order to continue the goal to make RESThub 2 a thin stack, and to not hide configuration to the developers.

[sdeleuze]

I have improved the Spring Context handling in RESThub in order to make it more flexible.

Application Context are not moved directly in the archetypes since it won't be easy to manage updates, but instead I have implemented the following changes :

• Each RESThub context file has a different name : resthubJpaContext.xml, resthubCommonContext.xml, resthubWebServerContext.xml or resthubMongodbContext.xml
• Default configuration in tests and servlet include automatically only classpath*:applicationContext.xml, RESThub context are not anymore included automagically
• RESThub context are explicitely included in archetypes or user projects thanks to import declaration like
• is included in resthubWebServerContext.xml, you don't have to specify it in your project anymore.

This way of handling contexts give more control about what is included or not, and explicit reference on context will help users to watch RESThub default configuration in order to include a modified version in their project if needed.

I have not moved resthubContext.xml