Entering content frame

Background documentation JNDI Support in PRT Locate the document in its SAP Library structure

The standard JNDI way to get access to JNDI factories assumes that the JNDI service provider classes are in the class path. However, the PRT implements a class loading separation feature that contradicts with the JNDI approach. You can use JNDI service providers without losing the benefits of class loading separation.

PRT JNDI Support Package

The PRT JNDI support package provides a different implementation of the following JNDI classes:

·        javax.naming.NamingManager

·        javax.naming.DirectoryManager

·        javax.naming.InitialContext

·        javax.naming.InitialDirContext

The standard JNDI implementation cannot find classes that are not in the classpath. The implementation that PRT provides simply changes the way the classes are loaded. More precisely, PRT tries its own mechanism and if it fails, delegates to the standard implementation.

The PRT implementation is delivered in a JAR File: prtjndisupport.jar. The following classes should be used to solve class loading issues:

·        com.sapportals.portal.prt.jndisupport.NamingManager

·        com.sapportals.portal.prt.jndisupport.DirectoryManager

·        com.sapportals.portal.prt.jndisupport.InitialContext

·        com.sapportals.portal.prt.jndisupport.InitialDirContext

Only the package name has been changed (not the class name). As a result, the impact on the code is minimal since changing the import statement might be sufficient.

JNDI Service Providers

To take advantage of the PRT JNDI support, JNDI service providers have to compile against this new com.sapportals.portal.prt.jndisupport package and delegate to the PRT implementation instead of calling directly the core classes provided by the javax.naming package.

Example

import com.sapportals.portal.prt.jndisupport.DirectoryManager;

// convert the persistenceObject to a semantic object

Object semanticObject;

semanticObject =

   DirectoryManager.getObjectInstance(null, name, this, env, objectAttributes);

JNDI Clients

JNDI clients have to change the way they get the InitialContext. They must use the PRT implementation of the InitialContext class instead of the standard one:

Example

import com.sapportals.portal.prt.jndisupport.InitialContext;

...

try {

   Context initialContext;

   Hashtable env = new Hashtable();

   env.put(

      Context.INITIAL_CONTEXT_FACTORY,

      "com.sapportals.portal.pcd.gl.PcdInitialContextFactory");

   initialContext = new InitialContext(env);

   Object o = initialContext.lookup(aName);

} catch (NamingException e) {

   e.printStackTrace();

}

JNDI Service Providers Packaging

A typical JNDI service provider is deployed in the portal the same way as any portal application by providing a PAR file. In order to register itself to the PRT JNDI Support, the application has to include a Java property file named jndiprovider.properties in its PAR file and be declared as “load-on-startup” in its deployment descriptor.

The location of this JNDI Provider Resource File in the PAR file must be:

·        /PORTAL-INF/properties/jndiprovider.properties

This file is a regular JNDI Provider resource file and when loading the portal application, PRT uses it to get the following JNDI properties:

·        java.naming.factory.initial

·        java.naming.factory.object

·        java.naming.factory.state

·        java.naming.factory.url.pkgs

This graphic is explained in the accompanying text

The properties for object and state factories may provide a colon-separated list of class names.

The PRT also expects additional properties from that file, which define the schemes that the JNDI Service Provider supports at runtime:

·        com.sapportals.portal.prt.jndisupport.scheme

·        com.sapportals.portal.prt.jndisupport.schemes

Example

The example shows a Travel Management Portal Application that wants to plug its content to the portal. This application could have its own factories and its own scheme.

The JNDI Provider Resource File is:

 

#

# Initial Context Factory

#

java.naming.factory.initial=com.sap.tm.application.TravelInitialContextFactory

 

#

# List of packages where to look for URL Context Factory

#

java.naming.factory.url.pkgs=com.sap.tm.jndi.providers

 

#

# Scheme supported by this JNDI service provider

#

com.sapportals.portal.prt.jndisupport.scheme=tm

 

#

# State factories

#

java.naming.factory.state=com.sap.tm.application.TravelStateFactory

#

 

#

# Object factories

#

java.naming.factory.object=com.sap.tm.application.TravelObjectFactory

#

 

Each factory declared in that file plays a specific role at runtime. The Initial Context Factory will be the root node to the specific content. The object factory is used to get the raw data from the persistence layer and to load it in the memory as Java objects; the state factory is used to update or store objects in the persistence layer, and the scheme avoids naming conflicts with other JNDI providers.

 

See also:

 

·        Starting Portal Objects

·        Portal Content Abstraction

 

 

Leaving content frame