Hi!
Let's step back a couple of posts...
MARK HAPNER wrote:
> In general, the content of JNDI initial context always depends on the
> app context within which it is created.
But never before has a JNDI context been dependent on who's calling,
which is the case now.
> 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.
I think it is. Where has this (this=caller specific contexts) been used
before, hence not being a new concept?
Some JNDI namespaces uses caller identification and authentication,
sure, but I don't know of any instance where the actual content of the
namespace is reliant on who calls lookup(). And even if it *is* reliant
on the identity of the caller, this is not the case here as the
component identity is not part of the environment used in the new
InitialContext() call.
> No 'trickery' is required to implement this JNDI naming policy. The
> java: namespace handler is provided by the EJB container and it
> implements this policy as easily as any other container facility.
To implement this you must use thread-associated caller identification.
And if one component calls another the caller id have to be stacked
(pushed upon call, popped upon call completion) to ensure correct
context switching. I'd call this "trickery".
There is also yet no standardized way to do the caller identification,
which is a necessity if one JNDI namespace implementation is to work for
all component engines in a VM. Which is a bad design, but doable.
> It is very important that J2EE provide a uniform mechanism for all
> components in all containers to access the envrionment that has been
> configured for them by their deployer. Defining a JNDI naming policy for
> this mechanism is an ideal way to accomplish this. It provides a level
> of consistency and integration that cannot be achieved by sprinkling
> various specialized lookup mechanism around the J2EE universe.
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. This might be "ok" for BEA and IBM
who has the programming power to implement all and everything, but for
others (including myself and EJBoss) it's a big problem. A showstopper
even.
The idea of having a uniform environment mechanism is good, using JNDI
to do it is bad, at least in the current form.
Even if we disregard the performance issues, it makes it completely
impossible to take partial J2EE implementations from different vendors
and put them together (i.e. JMS from vendor X, EJB from vendor Y, JSP
from vendor Z). Is that a design goal?? Because that is a consequence of
the current design.
Pleeeease tell me I'm wrong 8-) What have I missed?
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
