> 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,
Still a little confused. How do I provide the JNDI url property for a
JDK1.1.x client applet so that it can obtain the context for an EJB server?
If the #3 example is the way to go, which (if any) EJB vendors today support
this method?
I'm wanting to build an application for sale to other companies. I would
like to package the client classes into a jar, but provide a properties
capability for an implementation specific EJB server. I'm still not sure if
this is possible. Can you help a dummy like me?
-Ron
===========================================================================
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".
