Actually, the classpath: prefix will look in jar files so if you just reference the file names directly when creating the context list, you can keep them in the jar.
Here's an example. Suppose the "foo" module is packaged within "foo.jar". Also in the module (for the sake of argument, let's say at the root) is a file defining all the Spring beans: "foo-beans.xml".
Then, if you're doing this in a webapp environment (and defining a ContextLoaderListener), you could say:
Code:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:foo-beans.xml
<!-- Other bean files... -->
</param-value>
</context-param>
and the file will be loaded, even though it's in a JAR.
(The same goes if you're using a DispatcherServlet, creating an ApplicationContext by hand, etc.)
Now things can get very interesting in one other way. Suppose each module has a Spring Bean file with the same name (let's say "module-config.xml"). You can use the classpath* prefix to load each of these in a single line, like so:
Code:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath*:module-config.xml
</param-value>
</context-param>
I typically follow this pattern in my projects, as it provides a simple facade to the module config. Under the covers, you can always split the module-config into one or more XML files and use the <import> tag to include each within module-config.xml. For example, foo's module.config.xml might look something like this:
Code:
<beans ...>
<import resource="foo-services.xml"/>
<import resource="foo-daos.xml"/>
</beans>
Hope this helps
- Don