• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

regarding JNDI

Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Ranchers,
well I am working in ejb 3 in my current project but i dont know indepth of ejb, as only this time i just read about ejb first time, while doing this current project.
i don't understand the concept of JNDI, much can you please help me to know it .. here are some code from my project...

there is code "servicelocator.java" class doing jndi work whcih i didn't understand (pls explain me every stuff, step by step) and code that is calling it..


public class ServiceLocator {

private static InitialContext ic = null;

public static Object lookupEJB(String jndiName){
Object ejbObj = null;
try {
ejbObj = ic.lookup(jndiName);
} catch (NamingException e) {
return ejbObj;

static {
Properties properties = new Properties();
properties.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
properties.put("java.naming.factory.url.pkgs", "=org.jboss.naming rg.jnp.interfaces");
properties.put("java.naming.provider.url", "localhost:1099");
try {
ic = new InitialContext(properties);
} catch (NamingException e) {


the code that is calling above code is

private static final String JNDI_NAME = "ems/ManageMasterDataBean/local";
ManageMasterDataLocal manageMasterLocal = (ManageMasterDataLocal)ServiceLocator.lookupEJB(JNDI_NAME);

ManageMasterDataBean is the stateless session bean
ManageMasterDataLocal is the interface for teh session bean ManageMasterDataBean

ems is the name of the project

so my question is ..pls explain me the above stuff in details and tell me what is the significance of the local/remote and in what circumstances we will use that ... how we formulate JNDI name ?

please answer all these question if any body , can .. its a voluntary help that can benifit lots of new ranchers too..

please reply..
amit taneja
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
kindly reply pls
amit taneja
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
kindly reply...........still waiting for response
Posts: 10445
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the reasons why no one has answered this question might have to do with the fact that this needs lot of explanation if you are new to EJB. But, let me give it a try.

So your first question: What is difference between local and remote interfaces for EJB and when to use which?

Local interfaces are meant to be used when the EJB client will be part of the same JVM where the EJB is deployed. If the EJB client is on some other JVM (remote) then the remote interface comes into picture. When you use remote interfaces, the objects that get passed from the client to the EJB are serialized and deserialized. In case of local interfaces this is not the case, the objects are passed by reference. This is just a short explanation on remote and local interfaces.

Your next question: how we formulate JNDI name ?

JNDI name is just a name that you would use to identify the object that is bound in the JNDI tree. In case of EJB's the home objects are bound to the JNDI tree. The application will provide a unique name to be used to bind the home object in the JNDI tree.
If you look at the code that you have posted, there's something like:

Context ctx = new InitialContext();
Object obj = ctx.lookup("someName");

This is the point where you are doing the lookup of the object in the JNDI tree. First you get hold of the context in the JNDI tree and then do a lookup in that context.
author and cow tipper
Posts: 5009
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's an snipped from an article I wrote on JNDI. Maybe it's helpful.

You can find the orinal article at:

Understanding JNDI: Java Naming

I also have a few tutorials on using local interfaces and remote interfaces when creating EJBs. You might find that interesting as well.

Multimedia Tutorial on EJBs, EJB Clients and JNDI


-Cameron McKenzie

What is �Naming?�

JNDI, the Java Naming and Directory Interface, is one of the most important J2EE services your applications will employ.

J2EE components are interesting and powerful because the can take advantage of a variety of features and services that are implemented and managed by the J2EE application server; However, most of these services and features are created, initialized, maintained and exist outside of the Java code our developers write.

Applications must be capable of accessing these server managed J2EE services. The first step towards gaining access to these resources is looking them up through a directory naming service.

What J2EE components and services are accessed initially accessed through JNDI?

A short list of the elusive enterprise objects initially accessed though a naming service includes:

F Remote Enterprise JavaBeans
F DataSources
F Transaction Objects
F Custom Services
F Message Queues
F Local Enterprise JavaBeans
F Mail Servers

All enterprise environments, be it CORBA or .Net, use the facilities of a naming service. In a J2EE environment, the Java Naming and Directory Interface (JNDI) provides our components access to the underlying naming service implemented by the Application Server.

How does a naming service work?

When WebSphere boots, a variety of resources are initialized and subsequently bound to the naming service.

The first step in accessing a JNDI bound resource, such as an EJB, is to look up the resource according to its JNDI bound name. The naming service will then return to the client a reference to the object of interest.

A Conversation Between JNDI and an EJB at Start-Up

EJB: Hey, JNDI, do you know who I am?

JNDI: Ya, you�re a really important EJB.

EJB: That�s right, and people are going to be coming around these parts asking for me.

JNDI: What�s your name?

EJB: �ejb/com/pulpjava/session/Timer�

JNDI: Great. And when someone asks, where should I send them?

EJB: Point them to my home. It�s the big mansion on the corner.

JNDI: Will do! After all, binding names to objects is what I do best!

Who assigns resources their JNDI names?

When resources such as DataSources and message queues are created and configured by the administrator, the JNDI name is one of the configurable properties.

For the most part, the WebSphere administrator has the final say over the name a resource will use when binding itself to JNDI.

What is an InitialContext?

A naming service uses a directory, or folder structure, to keep track of objects and their corresponding names.

For example, EJBs usually go under a sub-directory named ejb, and database related objects usually go under a subdirectory named jdbc. An InitialContext is a connection to the root or base directory of the naming service, off of which all folders or subdirectories branch.

To use an analogy, if the Windows operating system was a directory server, the InitialContext would be the root, C:\, since all folders and subdirectories sprout from there.

Figure 18-1 Exploring a JNDI Tree

Objects are bound to a directory in a tree like structure.

When looking up an object bound to a JNDI server, we reference the name of the object relative to the root of the directory, or as we say in developerspeak, we reference the InitialContext.

How does JNDI help with distributed programming?

To obtain a reference to an EJB running on a remote server, we must first connect to the naming service on that server. Once we have a connection to the remote naming service, we provide the JNDI name of the desired EJB. If we provide the correct name, the naming service will return a reference to the EJB in question.

How do I look up a JNDI addressable resource?

When a connection pool is created, or an EJB is deployed, those resources are configured with a JNDI name.

A DataSource might be bound to the naming service with the name jdbc/pulpds, or and EJB might be bound with the name ejb/com/pulpjava/session/Timer.

To lookup a JNDI addressable resource in your application, your Java code would look something like this:

//connect to the root of the JNDI server

InitialContext jndi = new InitialContext();

//lookup a datasource


//lookup the Timer EJB


How does a resource reference work?

Of course, you would never, ever, want to hard code into your Java the name with which your EJB is bound to the naming service. There�s a whole whack of reasons why, not the least of which is the fact that the name you use to reference your EJB or DataSource at development time might be very different from the name the WebSphere Administrator gives to the resource at runtime.

�Develop one way, deploy another, and use configurable bindings to tie the two together.�

Figure 18-2 Configuring a Resource Reference in web.xml

The development name jdbc/ExamBankDS,which is mapped to the name jdbc/db2/ExamAppDS, which is the name used at runtime.

What is so bad about hard coding JNDI names into your code?

If you hardcode the names of JNDI addressable resources into your applications during the development phase, and the name of those resources happen to change at runtime, your applications will not work To avoid this problem, we use something called a resource reference to loosely bind the names used in our code to the actual name given to a J2EE resource at deployment time. At least, that�s what we should do.

How does a resource reference work?

Never hardcode a JNDI name in Java code. Code the name of a resource reference instead.

For example, if an EJB is bound to the JNDI server with the name ejb/com/pulpjava/session/Timer, a resource reference with the name ejb/Timer could be configured to point to this EJB.

In your code, you would perform a lookup against the name java:comp/env/ejb/Timer, which is the full name of the resource reference. The WebSphere environment recognizes anything under java:comp/env/ as a resource reference lookup. In this case, WebSphere will find a resource reference that binds the abstract name ejb/Timer with the actual ejb named ejb/com/pulpjava/session/Timer, and at runtime, a reference to the ejb/com/pulpjava/session/Timer will be returned to the client.

If the actual name of the EJB running on the server ever changes, the application assembler would only be required to change the binding between the resource reference and the actual name of the EJB. No change to the code would need to be made.

Resource references area great!

What does a resource reference lookup look like?

Resource references include the String �java:comp/env/� before the name of the configured reference name.

To look up an ejb with the JNDI bound name of ejb/com/pulpjava/session/Timer, using a resource reference of ejb/Timer, your code would look something like this:

//connect to the root of the JNDI server

InitialContext jndi = new InitialContext();

//lookup the ejb using the resource reference


//not using the reference�a bad practice


Notice how when using the resource reference, we use the prefix java:comp.

The last line of code in this example looks up the Timer EJB according to the name used when binding the timer to the naming service. This is not a scalable or easily maintainable solution, and should never be done in production code.

What does java:comp/env/ejb/Timer mean?

Interpreting java:comp/env/ejb/Timer goes something like this:

Using the connection to a JNDI server, connect to the common Java namespace (java
F Look for a component bound to the common environment of the name service (comp/env)
F Find, in the deployment descriptor of the calling resource, a reference for ejb/Timer
F Resolve the resource reference � in this case:

ejb/Timer (the resource reference)
resolves to

F Return to the client a reference to the resolved resource

Where are resource references stored and configured?

A resource reference is an abstract binding configured in the deployment descriptor of the J2EE module of the component that uses it.

For example, if a Servlet uses a resource reference, the deployment descriptor for the web module would contain the resource reference. If an EJB used a resource reference, the ejb-jar.xml file, which is the deployment descriptor for an EJB module, would contain the resource reference.

When the application assembler prepares the application for deployment, they will configure the bindings and make sure the abstract name in the web or ejb module maps to the appropriate resource running on the server. After all, the name of the resource in the development environment will likely be different from the name of the resource in the pre-production (pre-prod) or testing environment.

Again, develop one way, deploy another, and use configured bindings to tie the two together. Resource references make this happen.

Isn�t configuring resource references and doing these bindings a lot of work?

The extra configuration the administrator or application assembler must perform before deployment does constitute a bit of extra work, but it is not a huge burden. It sure beats having to dig into the code and fix all of the hard coded JNDI name references if the runtime name of a given resource ever changes. Besides, WebSphere Administrators never have much to do anyways � they like the extra work.

How has naming changed between WebSphere 4 and WebSphere 5?
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic