The JNDI Environment Properties
| Before the client can use the services offered by JNDI, it must first locate the service on the network and get a connection. It's sort of a paradox if you think about it. A client uses JNDI to locate remote services, but the JNDI service is possibly a remote service itself. So how is a naming service located if you don't have a naming service to start with? The JNDI answer is by using environment properties. Environment properties are the way that a JNDI client application communicates various preferences and properties that are used to establish a connection with the JNDI environment. Not only properties about where to find the JNDI naming service, but many more types of properties can be specified. For example, you might need to specify security credentials, such as a username and password, to connect to the naming service. A client can specify these by adding them to the JNDI environment properties. The properties are specific to a client. Each JNDI vendor implementation might have some common environment properties (such as where the JNDI service is), but also might contain specific properties (such as username and password of the client). Each JNDI service provider can use the properties in different ways. In fact, each provider might have provider-specific properties that are used only by it. The specific environment properties that must be defined for a client to connect to the naming service are provider-dependent. For example, for BEA's WebLogic EJB server, you must tell the client application that you will be using the WebLogic-provided JNDI service and where it can be found on the network. With the file system service provider, you will also need to set these environment properties, but the format and type of properties are somewhat different. Note Check with your JNDI provider documentation to see which properties are important and which ones are not for that specific provider. You might be wondering how a client can be portable if the properties are different across JNDI providers. As you'll see later in this chapter, you can specify these properties outside your code in properties files. This enables the client application to switch the properties without negatively affecting the application source code. Other information might be required depending on the SPI and naming service implementation. Typically, you will create a set of key/value pairs, where the keys are strings, which define a specific property. An example of one of these keys is java.naming.provider.url You must associate a value with this key. It might be something like this: ldap://ldap.wiz.com:389 The entire environment property might look like this: java.naming.provider.url=ldap://ldap.wiz.com:389 As you can see, the format is key = value . Table 4.1 describes all the standard environment properties that are available to a JNDI application and what each environment property is used for. Table 4.1. Standard Environment Properties That Can Be Used by JNDI
Note Notice that the property names specified in Table 4.1 have a prefix of java.naming and not javax.naming . You would think that because the APIs are defined in the javax.naming package, this would be the prefix, but it's not. Don't get the two confused . If you are including the JNDI packages in your applications, you will need to import javax.naming , but if you are using the environment property values, they begin with java.naming . For each environment property in Table 4.1, the javax.naming.Context interface also defines a static String constant that can be used programmatically. So, if you needed to specify the java.naming.initial.context property in your code, you could instead use the constant Context.INITIAL_CONTEXT_FACTORY It's recommended that you use these constants in your source code. Of course, you can't use them in the resource files or system properties, but using them in your source code will help with readability. Two environment properties are very important, no matter which service provider you are using. These two JNDI environment properties are
A client sets these two JNDI properties so that the naming service can be located. Most of the other environment properties are optional, but these two are generally required. The next two sections cover each of these two properties in detail. java.naming.factory.initialThis value is a string that holds the name specifying the initial context factory that should be used to create new InitialContext references. Note We have not covered what the Context or InitialContext objects are yet. For now, you can think of the Context as a reference to a binding within the naming service and the InitialContext as a reference to the root level of that naming service. If you imagine a tree hierarchy, the InitialContext reference is a reference to the top of the tree and a Context reference is a reference to a branch in the tree. The Context and InitialContext are covered in detail later in this chapter. The value of this property should be the fully qualified class name of the factory class to use. Here's an example using a BEA WebLogic JNDI factory: java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory If you don't specify the initial context factory property or if you specify it incorrectly, you will get a NoInitialContextException or possibly a NamingException thrown when attempting to connect to the naming service.
java.naming.provider.urlThis property value is also a string. This property holds the name of the environment value for specifying configuration information for the SPI to use. Although its syntax is somewhat dependent on the provider, the property typically follows the following format: protocol://host:port Here's an example using WebLogic: java.naming.provider.url=t3://localhost:7001 The protocol t3 you see here is a BEA-specific protocol. A few other protocols that you might see are iiop and ldap . This URL informs the SPI where the JNDI naming service is located so that objects can be found during a lookup. |
EAN: 2147483647
Pages: 223