Rickard writes:
There is no way for different component engines (e.g. servlet engine and
EJB container) living in the same VM to implement the same JNDI
namespace. When using URLContextFactories for lookup of "java:" URL's
the JNDI NamingManager chooses one from a list, and always the first
one, i.e. there is no way for multiple handlers, i.e. all component
engines must come from same vendor.
...
Pleeeease tell me I'm wrong 8-) What have I missed?
One thing I suspect you have missed is that in JNDI 1.2, it is possible
for different containers within a single VM to provide different
implementations of the "java:" namespace. (This was not the case in
JNDI 1.1.x.) This would be implemented by each container having its
own JNDI application resource file specifying the URL context factory
for its "java:" namespace.
Mark writes:
The java:/comp/env namespace is defined by EJB (and J2EE) to be
component relative. This is not in conflict with JNDI principles.
It is not a new concept.
Mark is absolutely right. Support for naming of this kind was among
the design goals of JNDI from day one.
Rickard writes:
But never before has a JNDI context been dependent on who's calling,
which is the case now.
I can't say that I can think of a JNDI implementation that does this.
Java's lack of the notion of a user (pre-JAAS) probably gets in the
way somewhat. But I can give other relevant examples, such as ~ in
the Unix C-shell. Or for a more obscure but more closely-related
example, the names _myself, _thishost, and _myorgunit in XFN.
Scott Seligman
Java Software Engineering
Sun Microsystems
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
