Tag Archives: cdi

Solving @inject null pointer exception

3 Comments

Getting a NullPointerException on @Inject ? In this post we’ll post a few possible solutions and things to check, that could explain the @inject null pointer exception.

Make sure your archive (jar, war, …) has a beans.xml file defined

The beans.xml file is known as the bean archive descriptor. Below you can find the most simple example with just a root beans xml element:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>

This file should be placed into META-INF/beans.xml or WEB-INF/beans.xml.
If you don’t include this file in your module archive, CDI injection will not be active for this archive as the container will not scan the archive.

There are a few reasons why the spec was done this way:

  • Performance: The container only has to scan the modules where you’ve added the beans.xml
  • The beans.xml also lets you define interceptors and decorators that have to be executed when the injection takes place.

When using CDI in some places, you have to use it everywhere

In CDI, the container manages the lifecycle of the objects it creates via the @Inject. What this means is that if you bundle a bean with an injected dependency into another object, the other object also has to be managed by CDI. Doing a new OtherObject() will not work; at least the @Inject will not be done.

Ambiguous dependencies for type problem fix

Leave a comment

When trying to @Inject an EJB inside a bean, it is possible that you’ll get an exception about ambiguous dependencies for type on Weblogic:

Oracle WebLogic Logo

Substituted for the exception org.jboss.weld.exceptions.DeploymentException which lacks a String contructor, original message - Exception List with 2 exceptions: Exception 0 : org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [ABC] with qualifiers [@Default] at injection point [[field] @Inject private ABCField]. Possible dependencies [[Session bean [class ABCImpl with qualifiers [@Any @Default]; local interfaces are [ABC], Managed Bean [class ABCImpl_7pbnr4_Impl] with qualifiers [@Any @Default]]]\

Solving the Ambiguous dependencies for type problem

The problem is that there are two possible implementations to inject and the CDI container doesn’t know which one to choose. You can also see that there seems to be a proxied/generated class to be listed (in our example ABCImpl_7pbnr4_Impl).

In our case this generated class was created by the Weblogic appc tool which was run on our EAR file. This ear file includes a JAR with EJB 2.x beans and another one with EJB 3.x beans<.

We solved this problem by not letting Weblogic appc being run on our EJB3.x jar. You can do this by running the Weblogic appc on individual jar files instead of the ear file. As you probably know EJB3 style beans don’t need an ejb compiler anymore to generate the remote and local interfaces as everything can be done with annotations.

PS: Weblogic uses Weld, the reference implementation of  Contexts and Dependency Injection in JavaEE.