16 Configuring and Programming JNDI

This chapter describes how to configure foreign Java Naming and Directory (JNDI) providers in Oracle WebLogic Server Multitenant (MT). This chapter also describes programming JNDI in a partitioned domain, including resource-scoped, object-based partition association, binding and obtaining partition information, accessing resources over partitions, and clustered JNDI in partitions.

This chapter includes the following sections:

Configuring Foreign JNDI Providers: Overview

WebLogic Server provides a foreign JNDI API that lets you access objects on a remote JNDI tree without having to connect directly to the remote tree.

In a partitioned environment, you can access objects on a JNDI tree either locally (in another partition on the same machine) or remotely.

By creating and configuring a foreign JNDI provider with the properties of the other partitions, you can look up and use an object that exists outside of a given partition. The properties that you set for the foreign JNDI provider are used to create a new context that internally does the actual lookup and bind operations.

Configuring Foreign JNDI Providers: Prerequisites

Prior to creating and configuring a foreign JNDI provider for a partition, you must:

  1. Create one or more virtual targets. For more information, see Configuring Virtual Targets.
  2. Create a resource group in the partition to use as the scope for the foreign JNDI provider in the partition. When creating the resource group, select one or more available virtual targets for the resource group. For more information, see Creating Resource Groups: Main Steps and Examples.

Configuring Foreign JNDI Providers: Main Steps

The procedure for configuring a foreign JNDI provider for a partition is the same as configuring one for a domain, with the following exceptions:

  • Set the scope of the foreign JNDI provider to a resource group in the partition.

  • If the foreign JNDI provider exists in a partition on another machine, then set the provider URL as if it were a common remote client. For example, for the t3 protocol, t3://hostname:port/partition_name.

To complete the foreign JDNI provider configuration, create one or more foreign JNDI links to associate local JNDI names with JNDI names on remote nodes.

Creating Foreign JNDI Providers: WLST Example

The following example shows how to use WebLogic Scripting Tool (WLST) to create a foreign JNDI provider and configure the user name, password, provider URL, and the InitialContextFactory for the provider. It also shows how to create a foreign JNDI link for the provider.

# Connect to the Administration Server

# Start an edit session

# Change to the appropriate resource group directory for the partition for which
# you are creating the foreign JNDI provider.
set('Password', 'password') 
# Create a foreign JNDI link and configure it

Programming JNDI in a Partitioned Environment

WebLogic Server MT supports multiple partitions running in one domain. A given WebLogic Server instance may have several partitions running in parallel. JNDI resources in a partition are isolated per partition. JNDI resources with the same JNDI name may reside in multiple partitions.

This section describes key points to be aware of when programming JNDI in a partitioned environment versus a nonpartitioned environment. It includes the following topics:

For additional information about programming JNDI, see Developing JNDI Applications for Oracle WebLogic Server.

Introduction to Partition-Scoped and Domain-Scoped JNDI Resources

In WebLogic Server, there is only one global JNDI tree that serves all requests for global JNDI resources. In WebLogic Server MT, however, there is a global JNDI tree for the domain and a global JNDI tree for each partition. JNDI resources in a partition are, by default, available only to the partition itself, although you can access such resources across partitions as described in Accessing JNDI Resources Remotely and Across Partitions. Therefore, by default, applications deployed at the partition level have access only to the JNDI resources within the partition and cannot access JNDI resources for other partitions or the domain.

For example, if you deploy an EJB with the global JNDI name java:global/foo to the domain and to multiple partitions on the same server, then this results in java:global/foo being bound to the global JNDI tree for each of these partitions and to the global JNDI tree for the domain. This results in the following behavior:

  • When you perform a lookup of java:global/foo from one partition, by default, JNDI returns the instance that is bound in the global JNDI tree for that partition.

  • When you perform a lookup of java:global/foo from the domain, JNDI returns the instance that is bound to the global JNDI tree for the domain.

Here are some additional examples:

  • mail.MedRecMail Session is bound to partitionA, partitionB, and the domain. JNDI lookup requests from an application in partitionA get the session for partitionA, while JNDI lookup requests from an application in partitionB get the session for partitionB. JNDI lookup requests from an application deployed in the domain will get the session for the domain.

  • weblogic.transaction.resources.dsXA is bound only to partitionB. Lookup requests from applications deployed in partitionB get the RmiDataSource. Requests from applications deployed in other partitions or the domain will get a NameNotFoundException exception.

  • java:global/wm/default is bound only at the domain level. Only applications deployed in the domain can access it by default.


Requests such as lookup or bind to application-scoped JNDI resources are isolated naturally because they are delegated to the application.

Object-Based Partition Association

When you create a JNDI context within a partition, the context object stays in the partition namespace so that all subsequent JNDI operations are done within the context of the partition. When the JNDI context is created, the association to a specific partition is established by the specified provider URL property. If you create the JNDI context with the java.naming.provider.url property set, then JNDI is partition-aware by looking up the partition information from the provider URL value. If you set the provider to be the virtual target URL that is configured for the partition, then JNDI creates the context for that partition and all requests from the context are delegated to the partition's JNDI resources.

After the object-based context has been created, its operations are performed using the partition JNDI tree.

Obtaining the Partition Information of a Context

Partition information is bound to the partition global JNDI tree when the partition tree is initialized. You can obtain the partition information of a context by looking up:

  • weblogic.partitionName, which returns the context-based partition's partitionName. This will either be a partition name or Domain if it is a domain-scoped context.

  • weblogic.partitionId, which returns the partition's partitionId. This will be zero, 0, if it is a domain or a value greater than 0 if it is a partition.

Accessing JNDI Resources Remotely and Across Partitions

Partition JNDI resources can be accessed from remote, standalone Java code using the WebLogic Server client or code that resides on a remote WebLogic Server instance. This is done by setting the provider URL in the same way as you would do if you were accessing a remote single server JNDI tree.

WebLogic Server JNDI also enhances foreign JNDI providers to allow one partition to declare only a local JNDI name but actually point to other partition JNDI resources. You can configure a link entry to associate a local JNDI name with a partition JNDI resource.

Cross-Partition Authentication

JNDI context authentication is done when the context is being created. WebLogic Server JNDI ensures that the authentication is processed in the partition to which the provider URL is associated, not the current partition. If no provider URL is set when creating the context, then the authentication is processed in the security realm associated with the current partition. The authenticated context is then pushed into the thread context for a permission check on the context in subsequent operations.

Clustered JNDI in a Partitioned Environment

The JNDI tree representing a cluster appears to the client as a single global tree. The tree containing the clusterwide services is actually replicated across each WebLogic Server instance or partition in the cluster.

In a multitenant environment, when setting replicate binding to a JNDI resource, the bind, unbind, and rebind events are exposed to all cluster nodes.

Life Cycle of a Partitioned JNDI Resource

WebLogic Server maintains the life cycle of partition JNDI resources according to the partition life cycle:

  • When a partition is created and started, the partition JNDI tree is created with the partition root node and becomes available.

  • When a partition is shutting down, the entire partition JNDI tree is deleted.

Creating Foreign JNDI Providers: Related Tasks and Links

See the following for additional information: