[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271165#comment-271165
]
Kristian Rosenvold commented on SUREFIRE-749:
---------------------------------------------
Yes the line you are looking at executes a single test-class, but unfortunately
you are looking in the wrong provider.
The JUnit4 provider is the classic no-frills JUnit4 executor. The moment you
switch to parallel you switch to the more modern
JUnitCoreProvider, which is a totally different beast.
You may actually be able to do what you want within the context of forking the
junit4 or the junit core provider and just doing everything yourself. You could
just put that on github or similar, making a derivate (forked) surefire
provider is really simple. It's going to be a fairly extensive change and I'm
have serious doubts if we will accept it as a contribution; but I'll keep an
open mind if you should decide to do it. Just be warned. The JUnitCore provider
is where all of the fun stuff happens, the Junit4 provider is basically a safe,
conservative version (and also the first junit 4 implementation).
BTW: You /did/ try just initializing the guice/log4j stuff in either a
@BeforeClass method (runs on a single thread) or simply use a static {} block
somewhere ? I suppose I'm half assuming you know these tricks. Making all the
tests synchronize on a single common static lock might also be viable.
> 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
