This chapter describes how to configure foreign JNDI providers in 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:
WebLogic Server provides a foreign JNDI API that enables you to 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 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:
Create one or more virtual targets. See Configuring Virtual Targets
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. See Creating Resource Groups: Main Steps and Examples.
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, set the provider URL like a common remote client. For example, for the t3 protocol,
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.
Example 17-1 shows how to use WLST to create a foreign JNDI provider and configure the username, password, provider URL and InitialContextFactory for the provider. It also shows how 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()
See the following sections and documentation for additional information:
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 non-partitioned environment. It includes the following sections:
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, 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 will get the session for partitionA, while JNDI lookup requests from an application in partitionB will 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 will get the RmiDataSource. Requests from applications deployed in other partitions or the domain will get a
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 sticks to 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, 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.
Once the object-based context has been created, its operations are done 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. 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 makes sure 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 cluster-wide 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 advertised 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 destroyed.