Unit test using the Reflections google library fai

Question

I am using the Google Reflections library for querying certain resources in the classpath. Those resources are located in the same location than the classes in my project.

I wrote some unit tests that succeed when executed as a unit test in Eclipse, but when I try to execute them with Maven (with a maven install for example), they are not working as expected. After some debugging, apparently the problem is that when executed with Maven, the Reflections library cannot find the classpath url where the resources are located.

I arrived to that conclusion researching how Reflections determines the classpath URLs that should be inspected. As an example, the following method shows how Reflections finds the available classpath URLs given a class loader (the original Reflections method has been simplified a bit):

public static Set<URL> forClassLoader(ClassLoader... classLoaders) {
    final Set<URL> result = Sets.newHashSet();
    for (ClassLoader classLoader : classLoaders) {
        while (classLoader != null) {
            if (classLoader instanceof URLClassLoader) {
                URL[] urls = ((URLClassLoader) classLoader).getURLs();
                if (urls != null) {
                    result.addAll(Sets.<URL>newHashSet(urls));
                }
            } 
            classLoader = classLoader.getParent();
        }
    }
    return result;
}

In short, it is traversing the class loader hierarchy asking for the URLs of each individual classloader.

When in Eclipse I invoke the previous method from a unit test with something like this:

    ClassLoader myClassClassLoader = <MyClass>.class.getClassLoader(); //<MyClass> is in the same classpath url than the resources I need to find
    Set<URL> urls = forClassLoader(myClassClassLoader);
    for(URL url : urls) {
      System.out.println("a url: " + url);

as expected, I can see (among many other URLs) the classpath URLs that are configured as part of my project:

file:<MY_PROJECT_PATH>/target/classes/
file:<MY_PROJECT_PATH>/target/test-classes/

and Reflections works as a charm (the resources Reflections should find are located in file:<MY_PROJECT_PATH>/target/classes/).

However, when the test is executed by Maven, I realized that these URL entries are missing from the set returned by the forClassLoader method, and the rest of the Reflections methods are not working as expected for this problem.

The "surprising" thing is that if I write this when the unit test is executed by maven:

ClassLoader myClassClassLoader = <MyClass>.class.getClassLoader();
url = myClassClassLoader.getResource("anExistingResource");
System.out.println("URL: "+url); //a valid URL

I can see that the class loader still can resolve the resource I am trying to find. I am puzzled about why when executed with Maven the forClassLoader method does not include in the returned set the classpath URLs of my project, although at the same time it is able to resolve resources that are located in such urls(!).

What is the reason of this behavior? Is there any workaround I can try to make the Reflections library work when invoked as part of a unit test run by Maven ?

Answer 1

I just encountered the same problem with Reflections library (version 0.9.11), only when executing unit tests from Maven builds. The link provided in the accepted answer pointed me in the right direction.

A simple POM file change to my Surefire plugin fixed this:

            <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <useSystemClassLoader>false</useSystemClassLoader>
            </configuration>
        </plugin>
        <plugin>
            <artifactId>maven-failsafe-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <useSystemClassLoader>false</useSystemClassLoader>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>integration-test</goal>
                        <goal>verify</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

The <useSystemClassLoader> config parameter defaults to 'true'. Forcing it to 'false' seems to resolve the classloader problem in my unit tests.

Answer 2

You're probably using M2Eclipse, which adds stuff to the classpath on its own. Command-line Maven works differently. You might find some options that will help.

Answer 3

I had the exact same problem. Adding following URL did the trick for me.

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setUrls(...);
cb.addUrls(YourClassName.class.getProtectionDomain().getCodeSource().getLocation());

Answer 4

Solved it. Posting the solution in case someone find the same problem in the future.

When executing the unit tests of a project, Maven does not (explicitly) include in the classpath all its dependencies. Instead, it declares a dependency on a tmp jar located in "target/surefire/surefirebooter_NUMBER_THAT_LOOKS_LIKE_TIME_STAMP.jar". This jar only contains a manifest file that declares a classpath for the project.

The method forClassLoader in the Reflections library does not return a set of urls with the effective classpath (i.e., classpath entries in manifest files are ignored). To overcome this, I just implemented this simple method:

public static Set<URL> effectiveClassPathUrls(ClassLoader... classLoaders) {
    return ClasspathHelper.forManifest(ClasspathHelper.forClassLoader(classLoaders));
}

The method forManifest (also part of the Reflections library) adds to the set of classpath urls sent as parameter, the missing classpath entries declared in manifest files of any jar files contained in the set. In this way the method returns a set of URLs with the effective classpath of the project.

Answer 5

There are a few issues you can create that makes surefire fail.

1. there is a naming convention; test suites should be called 'TestBlaBla' or 'BlaBlaTest'; beginning or ending with the word 'Test'.

2. as mentioned earlier, the classpath in Maven is more restricted than it is in Eclipse as Eclipse (stupidly) does not separate the compile classpath from the test classpath.

3. Surefire is free to run test cases from different test suites in any order. When running multiple test suites that initialize some common base (such as an in-memory database or a JNDI context) that can create conflicts where test suites start to influence each other. You need to take care to properly isolate test suites. Tricks I use are to use separate in-memory databases for suites, and I initialize shared things per unit test in stead of per test suite.

3 is the hardest to debug I can tell you; whenever something works in Eclipse and not in Maven I naturally assume I'm doing something wrong in isolating the test suite.