Using Classpath*: vs. Classpath: When Loading Spring Resources

I recently resolved a build problem nestled deep within the esoterica of spring resource loading. The behavior of classpath: URLs is explained at length in the Spring documentation, but, sadly, this is probably the last place a developer of my disposition would look.

The problem (which I describe in more detail beyond the fold) was that we were unable to load hibernate mapping files from our Spring configured integration tests even though they gave us no trouble in our web application. The solution was to replace the “classpath:” prefix of our mappingLocation URI with “classpath*:”. In this project, we are storing our Hibernate mapping files as separate files located in the package of the class they map (i.e. “Foo.hbm.xml” stored in “src/main/java/com/example/”).

We inherited the persisted classes and Hibernate and Spring configuration from another project. The sessionFactory configuration in spring specified the mappingLocations as “classpath:**/*.hbm.xml” which worked fine when we deployed the web application. But we soon ran into problems when we added integration tests to test new DAO functionality. The test configuration was not able to find any hibernate mappings even though we were using the same “classpath:**/*.hbm.xml” URI.

After a few hours of hair-pulling and a deep tour of the Spring source, we realized that the problem was that our test Spring configuration was in a different classpath root from the Hibernate mappings, even though both directories were in the test’s classpath. When you use ‘classpath:’ for an Ant style wildcard search, Spring uses a single classpath directory for the search. The documentation is vague, but it seems the directory returned will be the first one provided by ClassLoader.getResources(“”).

In our case, it returned the ‘/target/test-classes’ directory that contains applicationTest.xml and our test classes, instead of ‘/target/classes’ which contains application.xml and all the *.hbm.xml files.

Using the ‘classpath:’ prefix fixes the problem. It indicates that the resource loader should look in all directories on the classpath, so making this change solved our problem. Apparently Spring maintains both prefixes because limitations in the Classloader (at the specification level) make it difficult to search for resources in the classpath root when performing wildcard searches across all classpath directories. This suggest it might be good practice to always create a directory to contain resources you might otherwise want to put in the classpath root and always use the ‘claspath:’ prefix.