Hehe, how ironic - I sent a mail about this to sun yesterday, and now one
of the first letters I receive when joining this list is a very similar
"complaint". :)
My objection (besides the hack/"trickery") is that the container suddenly
has to keep an updated "active bean" <-> thread mapping which drains
performance (and yes, there is a thread <-> transaction mapping already
when there are active transactions but this adds some to the work). And
this goes for *every* bean-method invocation - not just the ones where the
context will be looked up (since this cannot be determined up front).
I oppose the current design and propose somehow getting a reference to the
context from the already existing EJBContext object - alternatively just
receiving a Map/similar interface instead. Most types of "enterprise
components" already, Servlet = ServletContext/ServletConfig, JSP =
PageContext, EJB = EJBContext, etc etc...
Any thoughts?
/Magnus Stenman
On Thu, 3 Jun 1999, 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.
>
> 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".
>
===========================================================================
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".
