The container can return an empty initial naming context (the JNDI
default) and set up a JNDI namespace handler for 'java:' using the
mechanism for this defined in the JNDI spec.
This actually requires less work than the previous mechanism which
typically required that the container provide a custom initial context
for resolving the JNDI names specified by the deployer (and stored as
environment properties).
A container will typically set up various thread local values that
identify the component, its transaction and security context, etc. Its
'java:' namespace handler uses the component identity to look up its
/comp/env entries.
I think once you investigate the details you will find that the JNDI
naming policy is both simpler for developers to use and simpler for
containers to implement than the previous dual environment property/JNDI
name mechanism. It does require container developers to understand a bit
more about JNDI.
Rickard �berg wrote:
>
> MARK HAPNER wrote:
> >
> > In general, the content of JNDI initial context always depends on the
> > app context within which it is created.
> >
> > 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.
> >
> > 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.
>
> Then you know something I don't. The only way I could see to implement
> this, and it seems others too, is to use thread associated context
> switching, which requires the caller to have done some setup before
> calling the JNDI namespace. Since this is not required for any other
> JNDI implementation I'd also call this "trickery".
>
> > 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.
>
> Agreed. So how do you suggest that the above "trickery" is avoided?
>
> /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".
===========================================================================
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".
