JNDI is a very generic API for exploring information namespaces organized in trees. Depending on the provider (like in JDBC, you need a concrete implementation called a provider that implements the functionality), you can use it to explore a file system, an LDAP server, or an abstract name/value pairs tree. In this last case, there is no constraints on the implementation. Some providers (the driver) use RMI as their communication protocol (like for Borland Enterprise server or the Sun reference implementation), others use HTTP (FioranoMQ's internal JNDI implementation is based on HTTP), while others use plain socket connection (Macromedia JRun4 is an example).

This explains the difference in configuration between the application servers. However, there are some common grounds: they all use at least one of the following properties

• Context.INITIAL_CONTEXT_FACTORY
  
• Context.PROVIDER_URL
  
• Context.SECURITY_PRINCIPAL
  
• Context.SECURITY_CREDENTIALS
  
• Context.URL_PKG_PREFIXES
  

hope that helps
laurent

The JNDI is just an API defined by the standard java packages. Somebody has to implement the underlying service.

Ok. Usually, the JNDI tree (that is, the naming service) is implemented by the J2EE server the application code is running on. In this case, you can use the default constructor of InitialContext and it will read the standard environment properties from the environment (that is, the appserver's specified environment).

However, if you need to locate, say, an EJB deployed into a separate physical machine on your network, you can't use the local JNDI tree - the remote object is bound only to one JNDI tree. In this case, the application code must somehow specify where to look for the JNDI tree before it can look for a bound object within the JNDI tree.

The "initial context factory class" and "JNDI provider URL" are the properties (and possibly username/password) that are needed to locate the JNDI tree.