Weblogic - How to Connect a Java Client to a Single Server with JNDI

Card Puncher Data Processing


In addition to the standard Java interfaces for JNDI, WebLogic Server provides its own implementation, weblogic.jndi.WLInitialContextFactory, that uses the standard JNDI interfaces.

The JNDI Service Provider Interface (SPI) provides an InitialContext implementation that allows remote Java clients to connect to an application Server. The client can specify standard JNDI environment properties that identify a particular Server deployment and related connection properties for logging in to the Server.


To interact with WebLogic Server, a Java client must be able to get an object reference for a remote object and invoke operations on the object. To accomplish this, the client application code must perform the following procedure:

  • Set up JNDI environment properties for the InitialContext.
  • Establish an InitialContext with WebLogic Server.
  • Use the Context to look up a named object in the WebLogic Server namespace.
  • Use the named object to get a reference for the remote object and invoke operations on the remote object.
  • Close the context.

Create environment properties

The first task that must be performed by any Java client application is to create environment properties.

The InitialContext factory uses various properties to customize the InitialContext for a specific environment.

You set these properties either by using:

  • a hashtable
  • the set() method
  • a jndi.properties file

of a WebLogic Environment object.

These properties, which are specified name-to-value pairs, determine how the WLInitialContextFactory creates the Context.

InitialContext Properties Definition Default
Context.PROVIDER_URL URL of the WebLogic Server that provides the name service. Local naming service: t3://localhost:7001.
Context.SECURITY_PRINCIPAL Identity of the User (that is, a User defined in a WebLogic Server security realm) for authentication purposes. Guest User unless the thread has already been associated with a WebLogic Server User.
Context.SECURITY_CREDENTIALS * Password for the User defined in the Context.SECURITY_PRINCIPAL property
* or an object that implements the weblogic.security.acl.UserInfo interface with the Context.SECURITY_CREDENTIALS property defined.

Obtaining a Context

Remote Client

Remote clients obtain an InitialContext from the WebLogic Server InitialContext factory. This class doesn't need to be instantiated directly. Instead, you can use the standard javax.naming.InitialContext class and set the appropriate hash table properties. All interaction is done through the javax.naming.Context interface, as described in the JNDI Javadoc.

Using a Hashtable

How to obtain a Context using the properties Context.INITIAL_CONTEXT_FACTORY and Context.PROVIDER_URL.

  Context ctx = null;
  Hashtable ht = new Hashtable();

  try {
    ctx = new InitialContext(ht);
    // Use the context in your program
  catch (NamingException e) {
    // a failure occurred
  finally {
    try {ctx.close();}
    catch (Exception e) {
      // a failure occurred

To use WebLogic JNDI, you must always set the java.naming.factory.initial property to weblogic.jndi.WLInitialContextFactory.

Using a Environment Object
weblogic.jndi.Environment environment = new weblogic.jndi.Environment();
InitialContext ctx = environment.getInitialContext();

Every time you create a new JNDI environment object, you are creating a new security scope. This security scope ends with a context.close() method.

Local Client

Within a Java EE component, you do not need to set up the Hashtable or Environment objects to define the connection information.

Each Java EE component within a Java EE application had its own component environment which is set up based on information contained in the component’s deployment descriptors.

Context ctx = new InitailContext();

Although it is possible for Java EE components to use the global environment directly, it is preferable to use the component environment.

Context Instantation

You do not need to specify a factory or a provider URL. By default, the context is created as a Context and is connected to the local naming service.

You can use the same properties on either a client or a server. If you define the properties:

  • on a server-side object, a local Context is used.
  • on a client or another WebLogic Server, the Context delegates to a remote Context running on the WebLogic Server specified by the Context.PROVIDER_URL property.

There are some properties that cannot be changed after the creation of the context. These properties include provider url, user credentials, and factories. AddToEnvironment can be used to change other properties after the creation of the context.


The mappedName value of the @Stateless annotation specify a new binding across all app servers. For example:

@Stateless(name="MyBean", mappedName="ejb/MyBean") 

Session Bean Mapped Name

JNDI naming convention is vendor specific (different between application server).


  • Glassfish. It uses a default JNDI name-binding for EJBs that don't specify one. The default name is printed out in the log.
  • Weblogic: mappedName#fully_qualified_name

With the weblogic JNDI tree,

Weblogic View Jndi Tree

you will find it under the Binding Name:

Weblogic Jndi Tree

Look Up a Named Object

The lookup() method on the Context is used to obtain named objects. The argument passed to the lookup() method is a string that contains the name of the desired object.

try { 
   ServiceBean bean = (ServiceBean)ctx.lookup("ejb.serviceBean");
}catch (NameNotFoundException e) {
  // binding does not exist
}catch (NamingException e) {
  // a failure occurred

where :

  • the names you use are the ones defined during the registration of your component.

For example with a deployment descriptor, if you have an ejb-ref in your deployment descriptor that looks like:


you would look up the name defined with the

setting, which in this case is “ejb1”
Closing the Context

After clients finish working with a Context, the client close the Context in order to release resources and avoid memory leaks.

If you attempt to close a context that was never instantiated because of an error, the Java client application throws an exception.

The client closes the context, releasing the resource being used.

try {
} catch () {
   //a failure occurred
Documentation / Reference

Share this page:
Follow us:
Task Runner