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.
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.
> Eric Halpern wrote:
>
> Vlada,
>
> I don't think the primary concern is with the overhead of creating an
> InitialContext. What seems wrong is that the Context obtained by
> looking up "java:comp/ejb" depends whose doing the lookup. It
> introduces the new notion into JNDI that names may be relative to an
> implicit Context, in this case the Context associated with the bean.
> Normally, one expects InitialContext.lookup("java:comp/ejb") to return
> the same Context regardless of the code path by which it was called
> (not considering the use environment properties for the moment). The
> EJB spec breaks this expectation and instead requires that the result
> of the lookup depend on the bean from which it was called. This has
> two problems:
>
> 1. It's implicit and unlike any other use of JNDI.
> 2. It requires trickery to implement.
>
> Providing a method on EJBContext that returns the appropriate
> javax.naming.Context, as Constantine suggests, seems like a much more
> desirable approach.
>
> Cheers, Eric
>
> Vlada Matena <[EMAIL PROTECTED]> wrote in message
> news:001101beab87$e3321f00$[EMAIL PROTECTED]...
> >
> > 1. The entries in the environment context are scoped to a home.
> >
> > 2. We decided to use "new InitialContext()" as the API for obtaining
> the
> > environment context to make the environment API uniform across all
> > the J2EE components types (i.e. enterprise beans, servlets, JSPs,
> > applets, and applications). We think that the constructor does not
> add
> > a whole lot of overhead to an instance start up.
> >
> > ----- Original Message -----
> > From: Constantine Plotnikov <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, May 31, 1999 6:14 AM
> > Subject: Re: EJB1.1 bean JNDI question
> >
> >
> > I think that for different homes there are different contexts.
> > I think that it is required to implement ejb-ref semantics in
> > XML DD.
> >
> > <ejb-ref>
> > <ejb-ref-name>ejb/EmplRecords</ejb-ref-name>
> > <ejb-ref-type>Entity</ejb-ref-type>
> > <home>com.wombat.empl.EmployeeRecordHome</home>
> > <remote>com.wombat.empl.EmployeeRecord</remote>
> > <ejb-link>EmployeeRecord</ejb-link>
> > </ejb-ref>
> >
> > ebj-ref.ejb-ref-name may be the same for
> > different types in different contexts.
> >
> > BTW I'm very amused why not return JNDI Context from
> > EJBContext. There will be the same URL for all beans
> > and it will be simpler and faster to get it from
> > EJBContext then to create it in specific bean context.
> > (Vlada or Mark, could you please explain it?).
> >
> > Considering it, implementing support for example
> > in B7 (p 288) in nontrivial. It is implementable
> > for example by setting thread context for bean
> > before bussiness method call, but why container
> > implementers need to deal with those problems
> > at all.
> >
> > from ejb spec 1.1 public draft (p 288)
> > > B.7 How to obtain database connections
> > >
> > > ...
> > >
> > > public class EmployeeServiceBean implements SessionBean {
> > > EJBContext ejbContext;
> > > public void changePhoneNumber(...) {
> > > ...
> > > // obtain the initial JNDI context
> > > Context initCtx = new InitialContext();
> > > // perform JNDI lookup to obtain resource factory
> > > javax.sql.DataSource ds = (javax.sql.DataSource)
> > > initCtx.lookup("java:comp/env/jdbc/EmployeeAppDB");
> > > // Invoke factory to obtain a resource. The security
> > > // principal for the resource is not given, and therefore
> > > // it will be configured by the Deployer.
> > > java.sql.Connection con = ds.getConnection();
> > > ...
> > > }
> > > }
> >
> >
> > Constantine
> >
> > Rickard ?berg wrote:
> > >
> > > On EJB1.1 bean JNDI environment.
> > > In EJB1.1 the bean retrieves contextual info from the
> "java:comp/env"
> > > JNDI name.
> > >
> > > Q: is this naming context local to each bean?
> > > I.e. if two beans lookup "java:comp/env" should they receive
> different
> > > contexts, or should they get the merged context of all beans?
> > > It seems from the spec as this would be contextual. This
> introduces some
> > > interesting implementation issues for container implementors
> (solvable,
> > > but still).
> > >
> > > Any ideas would be appreciated!
> > >
> > > /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".
> >
>
> ----------------------------------------------------------------------
>
> Eric Halpern BEA/WebLogic Team [EMAIL PROTECTED]
===========================================================================
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".
