You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jan Sievers (JIRA)" <ji...@codehaus.org> on 2012/02/01 14:41:02 UTC
[jira] (SUREFIRE-825) NPE in JUnit4TestChecker if
org.junit.runner.RunWith class can't be loaded by testClassloader
[ https://jira.codehaus.org/browse/SUREFIRE-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290475#comment-290475 ]
Jan Sievers commented on SUREFIRE-825:
--------------------------------------
If you think this issue is valid, I am willing to spend time on writing a unit test which mocks the package-filtering OSGi classloader to reproduce the issue standalone.
> NPE in JUnit4TestChecker if org.junit.runner.RunWith class can't be loaded by testClassloader
> ---------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-825
> URL: https://jira.codehaus.org/browse/SUREFIRE-825
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
> Affects Versions: 2.10
> Environment: tycho-surefire OSGi adapter
> Reporter: Jan Sievers
> Attachments: 0001-SUREFIRE-825-Add-null-check-for-runWith-field.patch
>
>
> This is a follow up on tycho-surefire bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=369266
> If the class org.junit.runner.RunWith can't be loaded by the test classloader, we get an NPE
> org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:123)
> at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:84)
> at org.eclipse.tycho.surefire.osgibooter.HeadlessTestApplication.run(HeadlessTestApplication.java:21)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
> Caused by: java.lang.NullPointerException
> at java.lang.Class.getAnnotation(Class.java:3027)
> at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.isValidJUnit4Test(JUnit4TestChecker.java:63)
> at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:52)
> at org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:80)
> at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
> ... 28 more
> This can happen in an OSGi classloader environment where classloading/visibility is controlled down to the package level.
> A test OSGi bundle may well only import package org.junit (containing the Test annotation, via MANIFEST header "Import-Package: org.junit"), but not package org.junit.runner.
> Thus org.junit.runner.RunWith can't be loaded by the test classloader and the runWith member in JUnit4TestChecker is null.
> Attached patch gracefully handles the null case simply by adding a null check.
> IMHO we can safely ignore the case where the RunWith class can't be loaded because if it can't be loaded, the test was not able to reference it at design time either, so it can't be annotated with @RunWith.
> Providing a standalone test case for this is hard as it only happens in an OSGi classloader environment...
> The sample project attached to the original tycho-surefire issue above demonstrates the problem. ('mvn clean integration-test' to reproduce)
--
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