On Jul 17, 2007, at 11:55 PM, Jacek Laskowski wrote:
Does it mean the InitialContext stuff should be where it belongs now, i.e. openejb-core?
The LocalInitialContextFactory should be in openejb-core, yes. It's what is used to embed OpenEJB (the core container system) into your vm. It has no remote capabilities and runs fine without any of the server jars (just need openejb-loader, openejb-jee, openejb- javaagent, and openejb-core). Both client and container (a.k.a. "server") run together in the same VM.
The LocalInitialContextFactory is what you'd use if you wanted a setup as shown in this picture where you are talking directly to an OpenEJB in your vm (i.e. the same vm as your client). An app doing this would be considered a Local EJB Client.
http://openejb.apache.org/images/diagram-local-server.gif
Does it mean that an end user has to put openejb-core on the classpath to connect to a remote openejb instance?
The openejb-core jar is not needed to connect to a remote openejb instance. The RemoteInitialContextFactory is in the openejb-client jar and it has no dependencies on any other part of OpenEJB, not even the openejb-core jar.
The RemoteInitialContextFactory is what you'd use if you wanted to connect to a instance of OpenEJB running in a different vm/process/ machine than the client. An app doing this would be considered a Remote EJB Client, which is what people typically think of when they imagine an EJB client.
http://openejb.apache.org/images/diagram-remote-server.gif -David
