JNDI's InitialContext
2 posts in topic
Flat View  Flat View

Posted By:   yunfeng_bai
Posted On:   Thursday, August 29, 2002 11:05 PM

I'm a novice about JNDI, and I'm always being confused in create the InitialContext's properties, such as INITIAL_CONTEXT_FACTORY, PROVIDER_URL, etc.. It seems that in different circumstance , such as in WebSphere or WebLogic, in EJB circmstance or Java Client App, the properties should change a bit too. could anyone here can summarize its usuage here? thanks a lot:-)

Re: JNDI's InitialContext

Posted By:   Laurent_Mihalkovic  
Posted On:   Friday, September 6, 2002 12:11 AM

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.PROVIDER_URL

hope that helps

Re: JNDI's InitialContext

Posted By:   Lasse_Koskela  
Posted On:   Friday, August 30, 2002 07:37 AM

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.

About | Sitemap | Contact