[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352062#comment-352062
]
Tibor Digana commented on SUREFIRE-749:
---------------------------------------
@Gili
My proposal would be for you to look around OSGi frameworks, Pax is very nice,
OSGi J2EE container, Weld 2.2.2 which supports parallel instances of J2EE
container.
Also in order not to rollback such of this feature, I would propose closing
this feature and reopen in Java 9, because the Jigsaw project has modularity
challanges.
BTW wasn't you who required same in JUnit opensource project in Github?
Look how many bugs are open, over 100 and nobody cares fix hem. Would you
instead help us, then you would understand that even a simple feature needs big
attention in maintenance and your private time.
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)
