In this article we will see an introduction to dependency management through JNDI (Java Naming and Directory Interface). We will see how to name resources with annotations and how to search dependencies are created. Furthermore, we see examples of using JNDI API and alternatives to search certain components.
The business logic of an application is not always independent, our implementation often depends on other resources that are in the application server such as JDBC, JMS, Session Bean and Entity Manager.
What is JNDI?
To manage these dependencies, Java EE components provides references to resources that are defined in metadata annotations or external. These references are nothing more than a link named to the resources that can be dynamically determined at runtime within the application code or automatically by the container when the component instance is created.
Every reference has a name and a destination. The name is used by the application code to determine dynamically the reference. The server uses the destination information to find the feature that the application is looking for.
Search for Dependency
The most traditional way of dependency management in Java EE is through search dependency in which the application code uses the Java Naming and Directory Interface (JNDI or) to locate a named reference.
The JNDI or Java Naming and Directory Interface is an API for accessing directory services. It allows client applications to discover and obtain data or objects via a name. Like all Java APIs, it is platform independent. Its two basic functions are :
- Associate (map) a feature with name
- Find a resource from its name.
All annotations resources support the name attribute that define the name of the reference. When the annotation feature is placed in the class definition, this attribute is mandatory. If the annotation is placed on an attribute or a setter method, the server will generate a default name. Usually annotations are put at the class level, and so the name is explicitly specified.
The name of the role is to provide a way for the client to locate the reference dynamically. All Java EE application server supports JNDI, and each component has its own local JNDI naming context that is called the environment naming context. The name of the reference is linked to the environment naming context, and when it is searched using the JNDI API, the server determines the reference and returns the reference destination.
Finding a dependency EJB
As an example we can consider the session bean below. In the example we have a dependency on a session bean by @ EJB annotation, the session bean is called “audit”, as defined in the “name” attribute. The attribute beanInterface only defines the business interface of the session bean that the client is concerned. @ PostConstruct in the session bean audit is located and stored in the attribute audit.
Context and InitialContext interfaces are defined both by the JNDI API. The lookup() method of the Context interface is the first point to return objects from a JNDI context. To find the reference audit, the application looks up the name java: comp/env/audit and makes a cast (conversion) result for the business interface AuditService.
The prefix java: comp/env/ added to the name of the reference to the server indicates that the environment naming context should be searched to find the reference. If the name is incorrect, an exception will be thrown when the search fails.
@ Stateless
@ EJB (name = "audit", beanInterface = AuditService.class)
public class implements DeptServiceBean DeptService {
private AuditService audit;
@ PostConstruct
public void init () {
try {
Context ctx = new InitialContext ();
audit = (AuditService) ctx.lookup ("java: comp/env/ audit");
} Catch (NamingException e) {
throw new EJBException (e);
}
}
// ...
}
Despite the above form to be valid and supported by large-scale Java EE components, we note that it is a little tricky to use it due to exception handling required by JNDI. EJBs also support an alternative syntax using a lookup() method of the interface EJBContext.
The interface EJBContext (and subinterfaces SessionContext and MessageDrivenContext) is available to any EJB and provide the bean with access to services at runtime such as timer services. The same example above is shown below using the lookup () method alternative. The instance SessionContext this example is provided via setter method.
Finding a dependency using EJB lookup
@ Stateless
@ EJB (name = "audit", beanInterface = AuditService.class)
public class implements DeptServiceBean DeptService {
SessionContext context;
AuditService audit;
public void setSessionContext (SessionContext context) {
this.context = context;
}
@ PostConstruct
public void init () {
audit = (AuditService) context.lookup ("audit");
}
// ...
}
The lookup() method of the EJBContext has two main advantages over the JNDI API:
- First is the argument to the method is exactly the name that was specified on the resource reference.
- The second advantage is that only runtime exceptions are thrown by the lookup() method, the other checked exceptions of API JNDI can be avoided. The management of exceptions are made automatically, but hidden from the client.
Summary
In this article we saw that an application depends on other components and we can use the search dependency to locate these components. One way is to use the JNDI API (Java Naming and Directory Interface) it allows client applications to discover and obtain data and objects via a name, or we can use an interface support to locate EJBs which in turn has some advantages in their use JNDI instead of the API.
Reference Articles on Dependency Injection
