[jira] (SUREFIRE-928) URL list returned from the class-loader when using 'manifest-only jar' configuration does not allow jar file scanning using java.net.URLClassLoader.getURLs()

["Kim Christian Swenson (JIRA)" <ji...@codehaus.org>]

Kim Christian Swenson created SUREFIRE-928:
----------------------------------------------

             Summary: URL list returned from the class-loader when using 'manifest-only jar' configuration does not allow jar file scanning using java.net.URLClassLoader.getURLs()
                 Key: SUREFIRE-928
                 URL: https://jira.codehaus.org/browse/SUREFIRE-928
             Project: Maven Surefire
          Issue Type: Bug
          Components: classloading
    Affects Versions: 2.12.4
         Environment: Maven 3.0.4, Windows, Oracle Java SE 1.6.0_30
            Reporter: Kim Christian Swenson
         Attachments: ClasspathConfiguration.diff, surefireclassloaderweaknessdemo.zip

Ref: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html

Consider a software module 'module-1' having the following properties:
1. Runtime class-path is too long for Windows command-line or environment variables.
2. ClassLoader.getSystemClassLoader() is used to scan class-path URLs.
3. Thread.currentThread().getContextClassLoader() is used to scan class-path URLs.

As I understand it the following then holds true:
(1) and (3) combined prevents us from using useSystemClassLoader=true with useManifestOnlyJar=false
(2) prevents us from using the Isolated class-loader as solved by setting useSystemClassLoader=false

What we really want is to use the 'manifest-only jar' configuration with the surefire-booter (which is the current 2.12.4 default configuration for surefire of useSystemClassLoader=true and useManifestOnlyJar=true), and for all class-loaders visible to module-1 to appear as if we did not have only the surefire-booter jar on the class-path when scanning elements from java.net.URLClassLoader.getURLs().

Attached surefireclassloaderweaknessdemo.zip which contains a minimal maven demo project with junit tests that fail in order to demonstrate this issue.

Attached ClasspathConfiguration.diff which is a 'git diff' suggestion on how to resolve this issue. I have put the text 'SUREFIRE-XXX' in the diff where 'XXX' should probably be replaced with the appropriate issue number (this issue).

Steps to reproduce:
1. Unzip attached surefireclassloaderweaknessdemo.zip
2. enter surefireclassloaderweaknessdemo folder and run 'mvn test'
3. Observe that unit-tests fail

Steps to make unit-tests pass:
1. Apply/patch attached ClasspathConfiguration.diff to git master (currently 2.13-SNAPSHOT)
2. Run 'mvn install' to update surefire 2.13-SNAPSHOT
3. Edit surefireclassloaderweaknessdemo/pom.xml and switch surefire plugin version to 2.13-SNAPSHOT
4. enter surefireclassloaderweaknessdemo folder and run 'mvn test'
5. Observe that unit-tests passes

The solution (as included in the diff file) uses reflection to access the 'java.net.URLClassLoader.addURL(java.net.URL)' method and adds elements that are available (they really are when using other parts of class-loader APIs) on the class-path.

I believe this solution should benefit all software run from surefire that attempt to scan the class-path using java.net.URLClassLoader.getURLs().

For those interested in where this issue turned up, read on:
This issue has turned up while working with a large web-application that uses apache Jasper to render JSP pages. The JspServlet does in fact search the list of URLs returned by ((URLClassLoader) Thread.currentThread().getContextClassLoader()).getURLs() for jars with META-INF folders containing tld (taglib) files. The symptoms were that under the default maven-surefire configuration (as also used in the attached demo project) the Jasper JSP compiler was unable to detect taglibs that were definetly there and worked in all other contexts (e.g. running junit embedded in Eclipse or IntelliJ IDE, running the application in deployed production context, running junit using a Gradle project file)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira