WELD-001408: Unsatisfied dependencies for type EntityManager with qualifiers @Named about cdi-unit HOT 4 OPEN

I have a similar problem with cdi-unit 4.1.0. I have tracked down the problem to the following:

In org.jglue.cdiunit.internal.WeldTestUrlDeployment#cdiClasspathEntries I end up having one entry for the test-classes folder of the current module, namely "file:/C:/Work/.../target/test-classes/" (please notice the upper-case "C" for the drive letter). In org.jglue.cdiunit.internal.WeldTestUrlDeployment:145 the current test class (in your case BookTest) is tested whether it is a CDI class using the org.jglue.cdiunit.internal.WeldTestUrlDeployment#isCdiClass method. Unfortunately in that method at line org.jglue.cdiunit.internal.WeldTestUrlDeployment:461 the returned URL location for the current test class is "file:/c:/Work/.../target/test-classes/". Please notice now the lower-case "c" for the drive letter. Due to this difference, the current test-class is considered as NOT being a CDI class, and is therefore not processed, meaning that the class itself and also nothing from its AdditionalClasses or AdditionalPackages is being added to the CDI bean deployment archive.

@BrynCooke Why is the current test class not directly being considered as a CDI class and processed accordingly? Wouldn't that solve a lot of such issues?

Somewhat related... @BrynCooke Why is the org.jglue.cdiunit.internal.TestConfiguration#additionalClasses always empty? shouldn't it be prefilled with the contents from the AdditionalClasses annotation on the test class?

from cdi-unit.

Same problem here. Tracked it down to surefire maven plugin's handling of class path to test class:
If test class resides on same path as windows temp directory, surefire adresses it with a relative class path (e.g. :/C:/Users/ME/AppData/Local/Temp/surefire849027778679875674/..%5C..%5C..%5C..%5C..%5C..%5Cprojekte%5Ccore-mbus%5Ccore-mbus-impl%5Ctarget%5Ctest-classes/)
Doesn't happen on other drives.

surefire maven plugin also has this covered: use 3.0.0-M2 or following.

from cdi-unit.

Hi,

The symptoms described here are very similar to the symptoms at #151.

The code which you are referencing was recently refactored and is not comparing the URL anymore.
See

Could you please check with cdi-unit built from the master branch?

from cdi-unit.

I am experiencing the exact same error with similar source code but in a Wildfly 26 environment. Not junit test case.
Should this be a different root cause then?

from cdi-unit.