(I apologize in advance for asking a question that may have an obvious answer).
I am getting familiar with JMS/JNDI as part of an enhancement to a middleware java application, (non-J2EE).
Is it always required that a JNDI "client" know the class name of the context factory? If not always, then when? I have not seen a good explanation of this simple but subtle characteristic of JNDI usage.
<background>
Most of the example code that I have seen that involves JNDI lookups, begins with specifying the InitialContextFactory class name in the environment properties passed to the InitialContext constructor.
(I have some sample code that runs without specifying the factory class, so I know that it works either way depending on conditions).
To me, this seems strange that a client trying to lookup some JNDI references would need to have such implementation-specific information. Consider a JMS client that just wants to access a queue. The client isn't interested in the type of JNDI provider, just getting access to the queue.
</background>
TIA
jrh
I am getting familiar with JMS/JNDI as part of an enhancement to a middleware java application, (non-J2EE).
Is it always required that a JNDI "client" know the class name of the context factory? If not always, then when? I have not seen a good explanation of this simple but subtle characteristic of JNDI usage.
<background>
Most of the example code that I have seen that involves JNDI lookups, begins with specifying the InitialContextFactory class name in the environment properties passed to the InitialContext constructor.
(I have some sample code that runs without specifying the factory class, so I know that it works either way depending on conditions).
To me, this seems strange that a client trying to lookup some JNDI references would need to have such implementation-specific information. Consider a JMS client that just wants to access a queue. The client isn't interested in the type of JNDI provider, just getting access to the queue.
</background>
TIA
jrh