Jim,
I can deal with startup properties and distribution of vendor specific
classes at runtime. I don't like having to modify code for vendor specific
implementations of JNDI interfaces.
-Ron
> -----Original Message-----
> From: James Cook [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 20, 1999 1:07 PM
> To: A mailing list for Enterprise JavaBeans development
> Cc: [EMAIL PROTECTED]; James Cook
> Subject: Re: Re: EJB client context
>
>
> I'm not sure if my other post got thru, but the actual client
> code does not
> change if you use a properties file to hold the context strings.
>
> The bigger question is all of the vendor specific support classes
> that must
> be distributed.
>
> jim
>
>
> ----- Original Message -----
> From: Ron Yust <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 20, 1999 12:37 PM
> Subject: Re: EJB client context
>
>
> My point (and concern) is that the server EJB bean is portable,
> but not the
> client. I don't want to change client code to access a different EJB
> vendor's product. I've got several examples on my desk each showing
> different code to configure the initial context for a particular
> EJB server.
> I don't want to have to do that! My client code is no longer portable.
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> > Sent: Wednesday, October 20, 1999 10:27 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: EJB client context
> >
> >
> > Hey
> >
> > > Ron Yust wrote:
> > > 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.
> >
> > That should indeed work with all servers. What other ways have you
> > found?
> >
> > /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".
