Spring gives multiple options to load XML resources for building contexts. the reference documentation does explain this feature quite well. However, I am taking my shot at explaining the different practical scenarios ( by order of growing modularisation)
For Example, A simplest Spring based web Context Loader can be configured with resources like this
You just need to put applicationContext.xml in WEB-INF/ folder of your webapp.
However, Typically an application is n-tiered. You can also have multiple files setup and in relative paths.
like
put them in WEB-INF/context-files folder.
But as Spring Conventions suggest, generally, applicationContext is generally the file that is defined in context loading, and the others are "imported" into the context
Again, as projects grow, each tier (service, dao .. ) are modularised into separate jars, so the respective config file(s) also move to those jars. so, referencing those xml files relatively will not work, because they are may be loaded by a different class loader. So to reference across class loaders
Further down, daos, themselves might be separated by components in applications
The above can be achieved using ant wild card like in
Getting the drift? Best is yet to come. You know you could actually have these context files loaded by different class loaders but in same application. Ex: EAR loading contexts in war and META-INF jars in separate class loaders. As Long as these are in the same VM, You can do a multi classloader resource look up like this:
There are other less used schemes like
For Example, A simplest Spring based web Context Loader can be configured with resources like this
<context-param> <param-name>contextConfigLocation</param-name> <param-value>applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>
You just need to put applicationContext.xml in WEB-INF/ folder of your webapp.
However, Typically an application is n-tiered. You can also have multiple files setup and in relative paths.
like
<param-value> context-files/applicationContext.xml context-files/dao.xml context-files/service.xml </param-value>
put them in WEB-INF/context-files folder.
But as Spring Conventions suggest, generally, applicationContext is generally the file that is defined in context loading, and the others are "imported" into the context
<param-value> context-files/applicationContext.xml </param-value>and in applicationContext.xml
<import resource="dao.xml"/>note that the resource is relative (no context-files/dao.xml)
Again, as projects grow, each tier (service, dao .. ) are modularised into separate jars, so the respective config file(s) also move to those jars. so, referencing those xml files relatively will not work, because they are may be loaded by a different class loader. So to reference across class loaders
<!-- applicationContext.xml is same, dao.xml is jar-ed in dao-module.jar under context-file/ --> <import resource="classpath:context-files/dao.xml"/>
Further down, daos, themselves might be separated by components in applications
<import resource="classpath:com/company/common/dao.xml"/> <import resource="classpath:com/company/order/dao.xml"/> <import resource="classpath:com/company/account/dao.xml"/> <import resource="classpath:com/company/account/legacy/dao.xml"/> <import resource="classpath:com/company/cs/dao.xml"/>
The above can be achieved using ant wild card like in
<!-- notice, the all directories and sub directories (account/legacy/ too) --> <import resource="classpath:com/company/**/dao.xml"/>
Getting the drift? Best is yet to come. You know you could actually have these context files loaded by different class loaders but in same application. Ex: EAR loading contexts in war and META-INF jars in separate class loaders. As Long as these are in the same VM, You can do a multi classloader resource look up like this:
<!-- notice, the asterisk --> <import resource="classpath*:com/company/**/dao.xml"/>
There are other less used schemes like
file: and http:. There are to be avoided in JEE for apparent reasons. Albeit, they are extremely useful in some scenarios, like, TestCases and WebServices.