CDI beans inside .jar are not found by the container (Unsatisfied dependencies)

Question

I have created a Java project to serve as a lib to other projects, reducing code duplication between projects. This lib project is exported to jar to be included in Web projects (WAR, not EAR).

In Web projects (where these classes are being removed) everything worked as usual while all classes were kept on them ─ the injection of simple and complex objects (those with Producers and settings) was working normally.

After removing these classes of the Web projects and add the jar with these same classes to the Web projects (setting this lib in pom.xml in Maven projects) everything is compiled normally, as it was before too. But on start the server, classes (CDI beans) now present in the jar are not found by the container during startup of CDI, generating this (famous) error:

WELD-001408: Unsatisfied dependencies for type Session with qualifiers (...)

Already added the beans.xml in the META-INF folder both in the src/main/resources (indicated in WELD and CDI documentation) as the root folder of the project.

Below are examples of beans (Session, SessionFactory and ExampleLogger) presents in the jar that needs to be injected into other projects (and have worked normally while the class was in the Web projects) but now is not being discovered by the CDI:

public class HibernateConnectionFactory {

    @Produces
    @ApplicationScoped @ConnectionBaseExample
    public SessionFactory createSessionFactoryExample() {
        Configuration configuration = new Configuration();
        configurarSessionFactory(configuration, "baseExampleDS");
        ServiceRegistry registry = new StandardServiceRegistryBuilder().applySettings(configuration.getProperties()).build();

        return configuration.buildSessionFactory(registry);
    }

    @Produces
    @RequestScoped @ConnectionBaseExample
    public Session createSessionExample(@ConnectionBaseExample SessionFactory sessionFactory) {
        return sessionFactory.openSession();
    }

    public void destruirSessionExemplo(@Disposes @ConnectionBaseExample Session session) {
        if (session.isOpen()) {
            session.close();
        }
    }
}

public class ExampleLoggerProducer {

    @Produces
    public ExampleLogger createLogger(InjectionPoint injectionPoint) {
        return new ExampleLogger(injectionPoint.getMember().getDeclaringClass());
    }
}

The problem occurs in the Maven projects and non-Maven projects as well. Has anyone faced this problem? Did anyone know a solution to the beans present in the jar be found by the container? Thank you in advance and sorry for the bad English.

Java EE7, CDI 1.1, WELD 2.1, server WildFly 8.1

Arria

This should work, so something is wrong in your setup. Are you sure the jar is included in the war? Did you change package names of the annotations (qualifiers)? Did you create a new simple bean in the jar project and try to have it injected in the war. Does that work? – Drilling

Yes, I have tried that. Trying again a little time ago I've found the solution ─ I placed the beans.xml on the META-INF folder inside the project root folder and it worked! That's against the description of how to work with CDI beans inside jars on WELD documentation, where says the place to put beans.xml is inside src/main/resources/META-INF, but is okay. Anyway, thanks Guenther. – Arria

Please look into your beans.xml. Does it specify bean-discovery-mode="annotated", if so, annotate the producer classes, at least with ApplicationScoped – Honshu

I tried both "annotated" and "all", but the problem was the way I was exporting the jar, using the export jar wizard of Eclipse instead of using Maven to do this. Thanks @Honshu – Arria

Answer 1

Trying again after a while I've found the solution ─ I placed the beans.xml on the META-INF folder inside the project root folder and it worked! That's against the description of how to work with CDI beans inside jars on WELD documentation, where says the place to put beans.xml is inside src/main/resources/META-INF, but is okay. Maybe in some Maven projects, that's true.

[UPDATE] This works because I was building the jar using the export jar wizard of Eclipse instead of using Maven to do this. Using Maven should works fine with beans.xml in src/main/resources/META-INF.

Hope this can help others on this situation too.

Arria

In this case, something is wrong with the way resources are processed in your maven setup. Maybe you redefined in your pom how resources are copied? The documented setup with src/main/resource/META-INF/beans.xml definitely works if you haven't messed with anything, as can be seen in numerous posts, e.g. #13056836 – Drilling

I think it's working this way because you are using Eclipse to export the jar file instead of using the artefact that is built by Maven. Ideally you would use Maven to build your distributed artefacts because this is a repeatable process, whereas Eclipse exports can be somewhat variable depending upon the user's individual setup. – Murder

@SteveC is right. I'm building using the export jar wizard of Eclipse instead of using Maven to do this. Using Maven to build with beans.xml in the indicated place works fine. Thank you both, I really appreciate your help and attention! – Arria

Answer 2

I have faced with the same symptoms in Eclipse with two projects. WAR project injected implementations from imported JAR library project. Maven compiled all correctly, but during running in local run-time environment bean manager could not resolve library beans, was unstable and sent mentioned exceptions.

Eclipse does not use Maven for preparing code for debugging, and its Project Facets were configured with Maven plugin. Maven dependencies were matched in both projects, but problem was in Eclipse project configuration.

My environment was JBoss EAP 6.4, and I have found that Maven plugin set up JAR CDI project facets but left default version 2.0. Run-time supports CDI 1.0 actually, and CDI project facets in WAR project had correct version.

In my case different versions of CDI project facets in WAR and imported JAR projects led to this exception. Manual Eclipse project facets version correction is required. With matched CDI versions between run-time environment and Eclipse project facets problem is gone.

Evildoer