Modular Spring Configuration
Automatically loading Spring configuration snippets from JAR files
When assembling applications from a set of reusable compoenents that use the Spring Framework to wire their beans you will end up with a whole bunch of Spring configuration snippets spread around the JAR files containing your components.
Components should be self-contained so everything belonging to the component (including configuration) should be part of it. Ideally assembling the application would just mean dropping an additional component JAR file into the classpath (i.e. adding dependency to its Maven POM) and using the beans it exposes.
A simple convention makes this quite easy: Just put a spring.xml file into the META-INF directory of your components and declare the application context in the application's web.xml like this:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath*:META-INF/spring.xml
/WEB-INF/applicationContext.xml
</param-value>
</context-param>
The result: For each component the contained spring.xml is added to the application context and any beans defined therein are automatically created on deployment.
To make sure no name clashes occur you should establish a simple naming conventions for the id attribute of your beans like component.beanname. Resources defined in the main application context that the components require like Hibernate sessions will be named core.beanname.
For example:
<bean id="pbx.pbxDao" class="com.reucon.astis.dao.hibernate.PbxHibernateDao"> <property name="sessionFactory" ref="core.sessionFactory"/> </bean>
Re: Modular Spring Configuration
The problem is that it becomes possible to introduce inter-modular dependency, and sometimes it can go without detection for a long time (if circular dependency is non-circular on the bean level). This fact makes it harder to keep sanity in place especially trying to maintain a product.
Re: Modular Spring Configuration
You are right that you must take care not to introduce unwanted dependencies between modules. These days you have additional options that you should consider to build modules with Spring like Spring Dynamic Modules for OSGi(tm) Service Platforms and dm Server.