• Menu
  • Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

JavaBeat

Java Tutorial Blog

  • Java
    • Java 7
    • Java 8
    • Java EE
    • Servlets
  • Spring Framework
    • Spring Tutorials
    • Spring 4 Tutorials
    • Spring Boot
  • JSF Tutorials
  • Most Popular
    • Binary Search Tree Traversal
    • Spring Batch Tutorial
    • AngularJS + Spring MVC
    • Spring Data JPA Tutorial
    • Packaging and Deploying Node.js
  • About Us
    • Join Us (JBC)
  • Java
    • Java 7
    • Java 8
    • Java EE
    • Servlets
  • Spring Framework
    • Spring Tutorials
    • Spring 4 Tutorials
    • Spring Boot
  • JSF Tutorials
  • Most Popular
    • Binary Search Tree Traversal
    • Spring Batch Tutorial
    • AngularJS + Spring MVC
    • Spring Data JPA Tutorial
    • Packaging and Deploying Node.js
  • About Us
    • Join Us (JBC)

Dependency Management with JNDI

August 29, 2013 //  by Manisha Patil//  Leave a Comment

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.

JNDI

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.

  • Annotations and Dependency Injection in EJB 3.0

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

  • Lars Vogel on DI
  • Wikipedia Reference
  • Contexts and Dependency Injection
  • Joe on DI with Spring

Category: JavaTag: JNDI

About Manisha Patil

Manisha S Patil, currently residing at Pune India. She is currently working as freelance writer for websites. She had earlier worked at Caritor Bangalore, TCS Bangalore and Sungard Pune. She has 5 years of experience in Java/J2EE technologies.

Previous Post: « Working with Threads in Java
Next Post: Border Radius, Box Shadow and Border Image in CSS3 »

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Follow Us

  • Facebook
  • Pinterest

FEATURED TUTORIALS

New Features in Spring Boot 1.4

Difference Between @RequestParam and @PathVariable in Spring MVC

What is new in Java 6.0 Collections API?

The Java 6.0 Compiler API

Introductiion to Jakarta Struts

What’s new in Struts 2.0? – Struts 2.0 Framework

JavaBeat

Copyright © by JavaBeat · All rights reserved
Privacy Policy | Contact