XML Config

import

Extract of text from 3.2.2.1. Composing XML-based configuration metadata:

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>

In this example, external bean definitions are being loaded from 3 files, services.xml, messageSource.xml, and themeSource.xml. All location paths are considered relative to the definition file doing the importing, so services.xml in this case must be in the same directory or classpath location as the file doing the importing, while messageSource.xml and themeSource.xml must be in a resources location below the location of the importing file. As you can see, a leading slash is actually ignored, but given that these are considered relative paths, it is probably better form not to use the slash at all. The contents of the files being imported must be valid XML bean definition files according to the Spring Schema or DTD, including the top level <beans\/> element.

Note:

• It is possible to reference files in parent directories using a relative ../ path. However, this is not recommended because it creates a dependency on a file that is outside the current application. This is in particular not recommended for classpath: URLs (e.g. classpath:../services.xml) where the runtime resolution process will pick the “nearest” classpath root and then look into its parent directory. This is fragile since classpath configuration changes may lead to a different directory being picked.

• You can always use fully qualified resource locations instead of relative paths: e.g. file:C:/config/services.xml or classpath:/config/services.xml. However, be aware that you are coupling your application’s configuration to specific absolute locations then. It is generally preferable to keep an indirection for such absolute locations, e.g. through ${...} placeholders that are resolved against JVM system properties at runtime.

  Other interesting notes on this subject: classpath*: making your Modular Spring Resources

  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 loaded by a different class loader. So to reference across class loaders

  <import  resource="classpath:context-files/dao.xml"/>