You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most parts of the modules are parallelizable, meaning that the parallel execution feature of JUnit Jupiter (and Spock after my PR was merged) can be used with the modules of this project.
But if you use MockBean.Builder#useUnmanaged with the default create function or MockBean.read which calls useUnmanaged internally, as soon as the according beans are resolved and thus created, they use WeldContainer.current() which blows up if multiple containers are running within the same JVM.
This can be taken care of consumer-side by using @Isolated for affected tests, but it would be nicer if possible, if the last bits of this project would also become parallelizable.
The text was updated successfully, but these errors were encountered:
Since this will now be documented, it is a low prio but a nice to have feature going forward.
We would have to find a way to either pass a BeanManager instance around or keep track of the running Weld container ID with which we can then retrieve the BM.
Most parts of the modules are parallelizable, meaning that the parallel execution feature of JUnit Jupiter (and Spock after my PR was merged) can be used with the modules of this project.
But if you use
MockBean.Builder#useUnmanaged
with the default create function orMockBean.read
which callsuseUnmanaged
internally, as soon as the according beans are resolved and thus created, they useWeldContainer.current()
which blows up if multiple containers are running within the same JVM.This can be taken care of consumer-side by using
@Isolated
for affected tests, but it would be nicer if possible, if the last bits of this project would also become parallelizable.The text was updated successfully, but these errors were encountered: