MARK HAPNER wrote:
> 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.
Ok, I understand the above, but I don't like it for said reasons.
'Tough' I guess...
Anyway, does this mean that the same will happen for the Servlet API?
I.e. getServletConfig in the Servlet interface will be deprecated in
favor of JNDI lookups.
/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".
