I think #3 is the way to go, but as you noted an InitialContext instantiated
with a default constructor will require some additional information. The EJB
1.1 server I am beta testing uses the JNDI 1.2 properties mechanism which
lets all the config params be defined in a jndi.properties file.
Until the 1.1 compliant servers are out I think it will depend largely on
which server you choose for development. Using a mechanism like Javier
posted, will give you the ability to abstract the lookup of EJB's. This
allows a simple code change in one class once the new servers come out,
instead of changing every client (or server) lookup.
BTW, examples #1 and #2 wouldn't actually work as posted...on any server.
They don't compile. You have to cast the result from ctx.lookup(). The EJB
spec is very adamant on using the PortableRemoteObject.narrow() mechanism,
so I would stick with the J2EE approach for now.
jim
----- Original Message -----
From: Ron Yust <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 20, 1999 5:03 PM
Subject: Re: EJB client context
> 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".
>
===========================================================================
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".
