Thanks Jim, I'm finally getting somewhere!
Now, which of the examples I provided should I code for? I'm assuming #3,
but I'm not clear how that example knows the URL for the EJB server. #2
seems to make more sense to me though. Will the #2 technique work in the
EJB 1.1 spec? What should I be using now? Can you give me a definitive
sample of how a client should obtain a EJB home object?
You can imagine my frustration when I can't even trust EJB books!
-Ron
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> Sent: Wednesday, October 20, 1999 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB client context
>
>
> 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.T3InitialCont
> extFactory
> > ");
> > 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".
>
>
===========================================================================
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".
