Ron,
Your examples may be dated, albeit relevant at this particular moment in
time. It's important to realize that there are no EJB books available yet on
the EJB 1.1 spec. This isn't too horrible since there isn't any commercial
EJB 1.1 server shipping yet.
There are two issues at hand here. The first one involves obtaining a
reference to the naming context and the other deals with "dereferencing" the
object's home interface.
Get the naming context
=======================
1. Server-side
Here it is from the "bible":
<spec type="ejb" section="18.2.1.3" version="Enterprise JavaBeans v1.1,
Public Release">
At the minimum, the EJB Container must provide a JNDI name space to the
enterprise bean instances. The EJB Container must make the name space
available to an instance when the instance invokes the
javax.naming.InitialContext default (no-arg) constructor.
</spec>
2. Client-side
We're not so lucky here, however the 1.1 compliant servers that I have used
in beta and the J2EE reference allows the same no-arg contructor [new
InitialContext()] to be used from the client. I couldn't find anything in
the J2EE or EJB 1.1 spec that addressed the requirements of obtaining the
initial context from the client's point of view.
Obtaining the home interface
=============================
<spec type="ejb" section="5.9" version="Enterprise JavaBeans v1.1, Public
Release">
A client program that is intended to be interoperable with all compliant EJB
Container implementations must use the
javax.rmi.PortableRemoteObject.narrow(...) method to perform type-narrowing
of the client-side representations of the home and remote interface.
Note: Programs using the cast operator for narrowing the remote and home
interfaces are likely to fail if the Container implementation uses RMI-IIOP
as the underlying communication transport.
</spec>
If your container vendor isn't supporting the no-arg constructor for looking
up the InitialContext, send them a note. There product is in beta, might as
well work on it now. Since the PortableRemoteObject mechanism is a matter of
public record, you don't have to use any strongarm tactics on your EJB
vendor.
jim
----- Original Message -----
From: Ron Yust <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 20, 1999 12:57 PM
Subject: Re: EJB client context
> > You are correct that obtaining the InitialContext requires different
> > parameters depending on the EJB container you are using, but the
> > process of
> > obtaining this context is the same. Portability is achieved by placing
the
> > vendor specific parameters in a properties file that is external to your
> > application.
>
>
> No, that's not right. Here are three examples:
>
> 1)---------------------------------------------
> Properties p = new Properties();
> p.put(com.genstone.naming.Defaults.NAME_SERVICE_HOST,"localhost");
> String port =
> System.getProperty("com.gemstone.naming.NameServicePort","10200");
> p.put(com.gemstone.naming.Defaults.NAME_SERVICE_PORT,port);
> p.put(Context.INITIAL_CONTEXT_FACTORY,"com.gemstone.naming.GsCtxFactory");
> Context ctx = new InitialContext(p);
> myEJBhome ejbHome = ctx.lookup("myEJBHome");
>
> 2)---------------------------------------------
> Properties p = new Properties();
>
p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.T3InitialContextFactory
> ");
> p.put(Context.PROVIDER_URL,"t3://localhost:7001");
> Context ctx = new InitialContext(p);
> myEJBhome ejbHome = ctx.lookup("myEJBHome");
>
> 3)---------------------------------------------
> Context ctx = new InitialContex();
> Object objref = ctx.lookup("myEJBHome");
> myEJBHome ejbHome =
> (myEJBHome)PortableRemoteObject.narrow(objref,myEJBHome.class);
>
>
> The first two examples are from O'Reilly's Enterprise JavaBeans book by
> Richard Monson-Haefel. Number one is for Gemstone/J and the second is for
> BEA's WebLogic Server. The third example is taken for Sun's tutorial on
> EJB. Each is different and requires programming beyond just supplying
> startup parms. Am I missing something?
>
> -Ron
>
> > ----- Original Message -----
> > From: Ron Yust <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 20, 1999 10:19 AM
> > Subject: EJB client context
> >
> >
> > > I'm setting up an EJB client application that would support
> > different EJB
> > > servers. I've discovered that the clients could have different
methods
> > for
> > > obtaining a JNDI context for each server depending on the EJB vendor.
> > > Doesn't this decrease the portability of EJB if I have to modify
client
> > code
> > > for each installation? I was hoping that it would be as simple
> > as coding
> > > Context.INITIAL_CONTEXT_FACTORY and Context.PROVIDER_URL properties
for
> > each
> > > vendor (which could be supplied as client startup properties) and then
> > > obtaining a InitialContext.
> > >
> > > Am I missing something? Has anyone gotten around this and developed a
> > > generic way for clients to obtain the server context? Thanks.
> > >
> > > Ron Yust
> > > Director of Information Services
> > > Empire District Electric Co.
> > > (417) 625-5126 voice
> > > (417) 625-5155 fax
> > >
> > >
> > >
> >
> > ==================================================================
> > =========
> > 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".
