Injecting EJBs using @Inject in class library

Question

I have a full-fledged Java EE application using GlassFish Server 4.1 / Java EE 7. It is a standard NetBeans project i.e. it does not use Apache Maven.

The application contains a class library named "ProjectLibrary" which is added to both the modules namely the EE module and the web module. The IDE shows the basic tree structure diagrammatically as follows.

There is a requirement to inject an EJB into a JPA entity listener as follows.

@ApplicationScoped
public class EntityListener {

    @Inject
    private Event<EntityChangeEvent> event;

    @EJB
    private UserService service;

    @PostPersist
    @PostUpdate
    @PostRemove
    public void onEntityChange(Entity entity) {
        event.fire(new EntityChangeEvent(Collections.singleton(service.getOwner(entity))));
    }
}

This listener is present in the EE project and the class library as well.

UserService is a stateless local EJB. This works coherently unless the annotation @EJB is replaced by @Inject in which case, the following exception is thrown.

Severe:   Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408: Unsatisfied dependencies for type UserService with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private entity.listeners.EntityListener.service
  at entity.listeners.EntityListener.service(EntityListener.java:0)
    at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:234)
    at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
    at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
    at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
    at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type UserService with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private entity.listeners.EntityListener.service
  at entity.listeners.EntityListener.service(EntityListener.java:0)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:370)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
    at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:515)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:490)
    at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:419)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
    at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
    ... 41 more

Severe:   Exception while loading the app
Severe:   Undeployment failed for context /Project-war
Finer:   initialize identitymaps
Warning:   session_manager_no_partition
Info:   No timers to be deleted for id: 94539334950977536
Info:   No timers to be deleted for id: 94539334950977536
Severe:   Exception while loading the app : CDI deployment failure:WELD-001408: Unsatisfied dependencies for type UserService with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private entity.listeners.EntityListener.service
  at entity.listeners.EntityListener.service(EntityListener.java:0)
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type UserService with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private entity.listeners.EntityListener.service
  at entity.listeners.EntityListener.service(EntityListener.java:0)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:370)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
    at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:515)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:490)
    at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:419)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
    at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
    at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
    at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
    at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
    at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)

Is it officially disallowed to inject EJBs using @Inject in class libraries?

GlassFish 4.1 uses Weld 2.2.2 final as the CDI implementation.

If you change the `@Stateless` with `@Dependent` does it deploy? — gurghet, Sep 16 '15 at 09:55
The behaviour remains unchanged, if the EJB is replaced by a `@Dependent` scoped CDI bean (the same exception is caused after applying this change). — Tiny, Sep 17 '15 at 03:28
Any reason why you want to change `@EJB` with `@Inject`, if it works? — Gas, Sep 17 '15 at 10:01
@Gas : `@Inject` enjoys higher precedence over `@EJB`, since Java EE 6. — Tiny, Sep 17 '15 at 10:05
For EJBs I find it better to use `@EJB` since just by looking at the code you already know what you are injecting, without inspecting other classes. As you see in your case, sometimes newer doesn't mean better. — Gas, Sep 17 '15 at 10:14
@Gas : Not in this particular case but at some other places, EJBs injected using `@EJB` will lack some CDI features like CDI interceptors. Therefore, it is to be taken into account. — Tiny, Sep 17 '15 at 10:23
Just curious, do you have `beans.xml` in the library project? — John Ament, Sep 17 '15 at 21:21
@JohnAment : There is no `beans.xml` in the library. It is merely used for sharing commonalities across both the modules. It is a simple JAR file containing no configuration location on its own. Nonetheless, I attempted to create `beans.xml` with `bean-discovery-mode="all"` in `META-INF` directly under `src` (`META-INF` does not exist on its own unless it is manually created). It made no difference either. `Event` is successfully injected by using `@Inject`. As such, there should not be a special case for EJBs to be injected by using `@Inject` in an application client library — Tiny, Sep 18 '15 at 05:38

score 1 · Accepted Answer · answered Sep 18 '15 at 12:01

1

If you fail to include a beans.xml in your application library, none of the components within it will be eligible for CDI injection, either as receiving injection points or as being injectable in to other components. When you added your beans.xml you made it so that your library could be injected into and its classes were now eligible to be injected using @Inject

It's a catch 22. The purpose of a library is that it has little outside dependency and has no knowledge of how its being used, so you wouldn't typically have CDI related code in it.

answered Sep 18 '15 at 12:01

John Ament

11,595
1
36
45

Isn't this behaviour very GlassFish specific or is an oversight in the CDI implementation and/or CDI specification. The JPA specification states, "*The persistence provider is only required to support CDI injection into entity listeners in Java EE container environments. If the CDI is not enabled, the persistence provider **must not invoke entity listeners** that depend upon CDI injection.*" The listener in the given example is dependent upon CDI injection (the `Event`). It is invoked, when the said EJB is injected by using `@EJB` i.e. CDI appears to have already been enabled there. – Tiny Sep 19 '15 at 06:23
Multiple specs have stated things they can't enforce. I doubt this is a glassfish specific issue, as it occurs in other containers. GF probably does it a little different, since they're default is for `beans.xml` at the root, e.g. the war in this case. Whats happening is that you're not getting any bean definitions created for EJBs in your library. – John Ament Sep 19 '15 at 12:54
Why is this mentioned in the [specification](https://docs.jboss.org/cdi/spec/1.0/html/packagingdeployment.html), "*A library jar, EJB jar, **application client jar** or rar archive is a bean archive if it has a file named `beans.xml` in the `META-INF` directory*"? – Tiny Sep 19 '15 at 15:30
Similar reasons. Those should all be bean archives, however it's not the CDI runtime that makes that call, it's the entire EE container who decides this. – John Ament Sep 19 '15 at 16:14

Injecting EJBs using @Inject in class library

1 Answers1

Linked