WELD-001408: Unsatisfied dependencies for type List with qualifiers

[abhi0123]

I'm stuck with the infamous WELD-001408 that everyone programming with CDI has come across in one way or other. Using Oracle JDK 1.8.0_25, Wildfly 8.2.0.Final. My code is as follows:

module availability-service (war) depends on module hospital-user (jar). Former has a beans.xml in WEB-INF and later in META-INF, even though CDI 1.1 doesn't require a beans.xml.

In hospital-user (producer):

@ApplicationScoped

public class Users {

    @Produces

    @Doctors

    public List<Doctor> getDoctors() {

        return getUsers("/doctors.json", Doctor.class);

    }

    @Produces

    @Patients

    public List<Patient> getPatients() {

        return getUsers("/patients.json", Patient.class);

    }

}

Doctors annotation (Patients is similar except for the name):

@Qualifier

@Retention(RUNTIME)

@Target({ FIELD, METHOD })

public @interface Doctors {

}

In availability-service (injection target):

@ApplicationScoped

public class AvailabilityService {

    @Inject

    @Doctors

    private List<Doctor> doctors;

}

Error:

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type List<Doctor> with qualifiers @Doctors

  at injection point [BackedAnnotatedField] @Inject @Doctors private name.abhijitsarkar.microservices.availability.AvailabilityService.doctors

  at name.abhijitsarkar.microservices.availability.AvailabilityService.doctors(AvailabilityService.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:372)

If I inject the Users instead of the List, it works. What is going on here?

For full disclosure, I've also asked this question on SO but didn't get a response.

[abhi0123]

Here's a sample Maven project that demonstrates the problem with 4 classes. Just run 'mvn clean test'.

[jharting]

Hi,

the maven project has "testable=false" on @Deployment which is the reason why the injected bean is null. After removing this "mvn clean test" passes for me locally.

[mkouba]

Jozef is right, if you set Deployment.testable() to false your test is not executed in the container - the client mode. See also Test run modes - Arquillian - Project Documentation Editor.

[abhi0123]

But how's the parent bean injection working in the original question, the one that contains @Produces?

[mkouba]

Abhi, I've got two questions:

1. Is hospital-user module a separate EJB jar?
2. Could you enable the debug logging and check whether the producer beans are recognized (see also http://weld.cdi-spec.org/documentation/#7)

[abhi0123]

Answer to q1 is yes, though not full blown EJB jar, just CDI.

It'll be a few days before I can answer q2. I'm in day 1 of a 2000 mile cross-country drive.

[mkouba]

Answer to q1 is yes, though not full blown EJB jar, just CDI.

In thi case, we would also need some more info about the deployment structure. If it's not an EJB jar, it must be a shared library. So I suppose your application is packaged as an EAR...

[abhi0123]

you're right, ear is the intended format though for now, I'm deploying as war. The module that's expecting the list to be injected is a web module with a dependency on the CDI jar module.

BTW, how do I enable Weld debug logs when testing in Arquillian?

[mkouba]

you're right, ear is the intended format though for now, I'm deploying as war. The module that's expecting the list to be injected is a web module with a dependency on the CDI jar module.

Ok. What's the bean discovery mode for the "CDI jar module"?

BTW, how do I enable Weld debug logs when testing in Arquillian?

If using managed or remote container simply modify the XML configuration file (${WF_HOME}/standalone/configuration/standalone.xml by default) and watch the ${WF_HOME}/standalone/log/server.log.

[abhi0123]

Sorry for the late response, as I said, I was on the road.

The bean discovery mode for the CDI jar module is ALL.

I'm using an Arquillian managed Wildfly that's downloaded by the maven-dependency-plugin for every build. It'd be difficult to automatically modify the standalone.xml for it. I guess I could work out a hack to copy a modified standalone.xml to the download location.

That said, it occurred to me that perhaps we should look at how the CDI jar is loaded into Arquillian to make sure that's right to begin with. I'm loading the dependency from the pom and I'm not sure there's anything in it that tells Arquillian to consider the beans.xml from that project. 

@Deployment

    public static WebArchive createDeployment() throws FileNotFoundException {

  File[] hospitalUser = Maven.configureResolver().workOffline()

  .withMavenCentralRepo(false).withClassPathResolution(true)

  .loadPomFromFile(new File("pom.xml"))

  .resolve(HOSPITAL_USER_MVN_COORD).withTransitivity().asFile();

  WebArchive app = create(WebArchive.class, SERVICE_NAME + ".war")

  .addPackages(true, Filters.exclude(".*Test.*"),

  AvailabilityApp.class.getPackage())

  .addAsWebInfResource(

  new File(WEB_APP_PATH, "WEB-INF/beans.xml"))

  .addAsLibraries(hospitalUser);

  System.out.println(app.toString(true));

  return app;

}

[mkouba]

The deployment method looks good. WRT the debug logging - the hack is not necessary. Simply copy the WildFly dist into a separate directory and point the JBOSS_HOME env variable there (or change jbossHome in the container config in arquillian.xml).