Project that tries to illustrate error:
https://drive.google.com/file/d/0B_dEiNBGUsxqaG5tdTVuT2RqT00/edit?usp=sharing

Summary:

• surefire threaded option
• test thread calls weld.shutdown()
• all other threads still working will have random problems using their own non shared weld containers

Context:
I am creating some UI Tests based on selenium. UI testing is overall a slow process with the opening of the browser and all the orchestration, so multi-threading the tests is a must.

Initially I was using Google Guice for IoC, but I have switched to weld.
The UI tests used to be successful in Guice using surefire <threadCound></threadCoun> configuration property.
When I switched to Weld, this stopped being the case.
The tests consistently break with several different exceptions at several different points of the life cycle of the test.

Summary of test policy:
Each test class contains a Weld and WeldContainer object that is unique to itself and not shared in any way. There are no race conditions on these objects, since each test class contains a single test, and each test is given a single thread by the surefire plugin.

What seems to be happening here is that the
weld.shutdown();

call seems to have a cross cutting power across all the running threads.
That is, even though each test class has its own weld object that it uses to create a weld container.
As soon as the first test thread concludes the test and reaches the tearDown() moment, and invokes weld.shutdown(), from this point onward the ramaining tests seem to start dieing with arbitrary exceptions.

For example, I have head tests where the container.initilize() appears to be very successful, but after that trying to get a bean from the container will result in a:
WELD-001308 Unable to resolve any beans for Types:

Other tests that seem to have passe the @Test() point ad have reached teh tearDown() phase, these will failing trying to close the weld instance variable with arbtirary erros, such as:

java.lang.NullPointerException
at org.jboss.weld.environment.se.ShutdownManager.shutdown(ShutdownManager.java:42)
at org.jboss.weld.environment.se.ShutdownManager$Proxy$$$_WeldClientProxy.shutdown(ShutdownManager$Proxy$$$_WeldClientProxy.java)
at org.jboss.weld.environment.se.Weld.shutdown(Weld.java:218)

Or such as:
java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52)
at org.jboss.weld.Container.instance(Container.java:67)
at org.jboss.weld.bean.AbstractBean.initialize(AbstractBean.java:134)
at org.jboss.weld.bean.AbstractClassBean.initialize(AbstractClassBean.java:205)
at org.jboss.weld.bean.ManagedBean.initialize(ManagedBean.java:327)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:116)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:217)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:365)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.deployBeans(ForwardingBootstrap.java:70)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:137)
at WeldBugReportSurefireTest.setUp(WeldBugReportSurefireTest.java:65)

It is very hard to decide on an exception to report, so many take place an arbitrarly.

To make the tests pass I have have to use surefire configured for forking, witout re-use of forks. This solves my multi-threading issue.
But I am concerned with the erros I am getting, because I can envision scenarios where an application really needs to created different container objects that it shutsdown when appropriate without disturbing the other opened containers, as you can do with guice.

I have tried to compile a small project where this error can be reproduced.
I cannot use the real project for privacy reasons, so the exceptions that my sample project yields do not correspond exactly to the ones I get in my project...

In this project, tests can be triggered through the comand line with either:
mvn test
mvn -P parallel test
the mvn test runs one test at a time, the normal way, and should be successful.
the mvn -P parallel test
should break most of the time with arbitrary exceptions on arbitrary test classes

And if the managed bean DummyManagedBean.java has a flag property that can be used to get the tests to pass when in parallel.
what this flag will do is make the thread postpone the test for long enough, for all other threads to complete their business logic, thus avoiding a weld shutdown to occur before the tests complete.