[jira] Commented: (SUREFIRE-335) forkMode = none is incompatible with useSystemClassLoader = true
[ http://jira.codehaus.org/browse/SUREFIRE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114628 ] Dan Fabulich commented on SUREFIRE-335: --- I don't understand this bug at all. As noted, you can't modify the system classpath once you're running (hence the need to fork). It sounds like you're imagining an alternate meaning of useSystemClassloader which would merely copy the system classloader (or just inherit from it)? Why would you want that? Are you saying that it would have helped solve the CNFE you had with your Archiva test? How? forkMode = none is incompatible with useSystemClassLoader = true Key: SUREFIRE-335 URL: http://jira.codehaus.org/browse/SUREFIRE-335 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.3 Reporter: Brett Porter Assignee: Brett Porter Fix For: 2.3.1 these options are obviously not compatible as the method of implementation of the latter requires forking. An alternate implementation should be used that includes the system class loader However, the following occurs in Archiva: Caused by: java.lang.ClassNotFoundException: org.apache.maven.archiva.configuration.ArchivaConfigurationTest at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:87) ... 27 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-335) forkMode = none is incompatible with useSystemClassLoader = true
[ http://jira.codehaus.org/browse/SUREFIRE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113322 ] Marat Radchenko commented on SUREFIRE-335: -- Well, actually it cannot be compatible (and stable) because you cannot modify bootclasspath of JVM you're running in. The only way you can modify bootclasspath is to fork another JVM. However I wonder, what JVMs require useSystemClassLoader trick? forkMode = none is incompatible with useSystemClassLoader = true Key: SUREFIRE-335 URL: http://jira.codehaus.org/browse/SUREFIRE-335 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.3 Reporter: Brett Porter Assignee: Brett Porter Fix For: 2.3.1 these options are obviously not compatible as the method of implementation of the latter requires forking. An alternate implementation should be used that includes the system class loader However, the following occurs in Archiva: Caused by: java.lang.ClassNotFoundException: org.apache.maven.archiva.configuration.ArchivaConfigurationTest at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:87) ... 27 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira