[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271242#comment-271242
]
Kristian Rosenvold commented on SUREFIRE-749:
---------------------------------------------
You'd have to test if loading the class object in different classloaders
actually works. But remember that JUnit instantiates one instance per test, so
you'd still be left with multiple instances from the same classloader when
there are several methods in one class. How does that solve anything for
methods ? (You might be able to run classes parallel...)
The class objects are being loaded in class "DefaultDirectoryScanner" line 78.
I recommend you just clone surefire on github
(https://github.com/apache/maven-surefire) ,fork the provider use your custom
fork as described here
http://maven.apache.org/plugins/maven-surefire-plugin/examples/providers.html.
Using this setup makes it quite easy to experiment and play around with this
stuff.
If your patch turns out to be really simple and works really well I'll consider
it, especially if there's tests. After all we're not totally mean :-)
> Parallel methods should run in separate classloaders
> ----------------------------------------------------
>
> Key: SUREFIRE-749
> URL: https://jira.codehaus.org/browse/SUREFIRE-749
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support
> Affects Versions: 2.8.1
> Reporter: Gili
>
> When running in parallel-method or parallel-both mode, each @Test should run
> in its own ClassLoader. I'm running into a lot of problems involving the use
> of static variables in 3rd-party libraries. Here are two examples:
> 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176
> 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635
> I believe running in isolated ClassLoaders would fix both problems and it
> makes a lot of sense from a test isolation point of view so we should do it
> anyway.
> I believe Surefire's forkMode is defined in terms of isolated JVMs instead of
> ClassLoaders. Furthermore, it only seems to support per-Class isolation
> instead of per-@Test isolation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
