Option 1 (should be preferred as it's the best practice):
Refactor your config files under WEB-INF
and move the common parts (that you want to access also from integration tests) to src/main/resources/
. Then write test specific configuration files in src/test/resources/
(if you only need to import several different config files from src/main
to assemble your test context, then skip this, and use @ContextConfiguration
preferably).
Option 2 (hack):
Use references like:
@ContextConfiguration("file:src/main/webapp/WEB-INF/dataSource.xml")
Option 3 (hack):
If you have a Maven project, you can configure the maven-surefire-plugin
(used in the test phase) to declare src/main/webapp
as an additional classpath element during test execution.
The latter two options are considered as hack, because files under src/main/webapp
are simply not supposed to be on the classpath.
Now the detailed explanation:
The reason why you can't refer to these files as classpath:/WEB-INF/*.xml
is that they are indeed not on the classpath. It's important to understand how your webapp is packaged, and what exactly ends up on the classpath. Assuming a default Maven project structure:
- Java classes from
src/main/java
go to /WEB-INF/classes
after compilation.
- Resources from
src/main/resources
go to /WEB-INF/classes
as well.
- Project dependencies go to
/WEB-INF/lib
.
- Everything you have in
src/main/webapp
goes to /
(root of the package). This means that all files from src/main/webapp/WEB-INF
go to /WEB-INF
, of course.
The most important thing to know is that the classpath will only contain /WEB-INF/classes
and one entry for each jar in /WEB-INF/lib
. Consequently, resources outside these two locations are completely invisible for the classloader. This is also true for the xml config files directly under /WEB-INF
, which is why the reference classpath:/WEB-INF/dataSource.xml
will never work.
You may ask yourself, how the hell are then these xml config files loaded by Spring if they are not reachable from the classpath? The answer is simple: When you start your webapp (as opposed to executing just unit/integration tests), it is running in a Servlet Container which provides access to the ServletContext
(an actual class from the Servlet API), so it uses ServletContext.getResourceAsStream()
to load these files. The key for understanding is the following quote from the javadoc of this method:
This method is different from java.lang.Class.getResourceAsStream, which uses a class loader. This method allows servlet containers to make a resource available to a servlet from any location, without using a class loader.
Sorry this become way too long, but that's the whole story...
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…