Learn how to configure foreign Java Naming and Directory (JNDI) providers in Oracle WebLogic Server Multitenant (MT), including programming JNDI in a partitioned domain, 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:
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.
Prior to creating and configuring a foreign JNDI provider for a partition, you must perform certain prerequisite steps.
The procedure for configuring a foreign JNDI provider for a partition is the same as configuring one for a domain, with some 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.
You can 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. Also, to create a foreign JNDI link for the provider.
# Connect to the Administration Server
connect('adminusername','adminpassword','t3://hostname:port')
# Start an edit session
edit()
startEdit()
# Change to the appropriate resource group directory for the partition for which
# you are creating the foreign JNDI provider.
cd('/Partitions/partition_name/ResourceGroups/resource_group_name')
cmo.createForeignJNDIProvider('provider_name')
cd('ForeignJNDIProviders/provider_name')
set('Password', 'password')
cmo.setUser('username')
cmo.setProviderURL('t3://hostname:port')
cmo.setInitialContextFactory('initialContextFactory')
# Create a foreign JNDI link and configure it
cmo.createForeignJNDILink('link_name')
cd('ForeignJNDILinks/link_name')
cmo.setLocalJNDIName('local_JNDI_name')
cmo.setRemoteJNDIName('remote_JNDI_name')
save()
activate()Learn key points to be aware of when programming JNDI in a partitioned environment versus a nonpartitioned environment.
For additional information about programming JNDI, see Developing JNDI Applications for Oracle WebLogic Server.
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.
Note:
Requests such as lookup or bind to application-scoped JNDI resources are isolated naturally because they are delegated to the application.
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.
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.
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.
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.
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.
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.