Rickard �berg wrote:
> Hey
>
> Constantine Plotnikov wrote:
> > I see there following alternatives in API:
> >
> > a) make method that return JNDI context
> > for example:
> > CartHome h = (CartHome)ctx.getContext().lookup("ejb/Carts");
> >
> > b) make method that lookup resource for bean:
> > for example:
> > CartHome h = (CartHome)ctx.getResource("ejb/Carts");
> >
> > There may be alternatives for naming of this method:
> > for example:
> > * lookupResource()
> > * getResource()
> > * lookupService()
> > * getService()
> > * feel fre to come with better name/
> >
> > I like (b) more because it is more close to semantics of resolving
> > external references and do not req1uire knowledge of JNDI from
> > bean developer (which is good IMHO).
>
> Since there isn't much more than "lookup" that should be supported for
> the bean, I agree that b is better. I'd vote for getResource! :-)
>
> Which would remove the JNDI thing altogether, although
> ctx.getResource("ejb") will return a javax.naming.Context.
>
I disagree. Option A is much better. Obtaining the environment naming context
from EJBContext will keep the API flexible so that new, unanticipated,
resources that are not properites, EJB homes or resource factories can be
supported. If you explicitly define the types entries available from the
environment naming context the list of methods will grow with every new spec.
Perhaps option A should be:
EJBContext.lookup( );
EJBContext could become a javax.naming.Context.
--
Richard Monson-Haefel
Senior Consultant
BORN Information Services
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
(Available June 1999)
===========================================================================
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".
