Solution to get back local or remote
I have a simple bean declared like this
@Local(LocalInt.class)
@Remote(RemoteInt.class)
@Stateless(name="name")
public MyEJB_Implementation {
//methods
}
As you can see, this is the only bean that has a local interface (for local clients) and a remote interface (for remote clients).
Clients (remote and local) retrieve the instance as follows:
ctx = new InitialContext(environment);
ctx.lookup("name");
How does a Container decide if it will provide a proxy that implements an interface LocalInt
or an interface RemoteInt
? (since I am using the same "name" for searches).
What I mean is that the JNDI registry somehow knows if the search is in the same JVM or from a remote server?
And also does this difference (for local and remote calls) clash with the semantics of "search"? (which should have exactly zero or one object registered for the same name, in this case there seem to be 2 objects (local and remote) under the same name).
Thank.
source to share
In my experience, a container will return an interface local
when clients are in the same container (EAR or WAR) and when outside of that an interface is returned remote
.
I'm not sure if this is stated in the Java EE spec, but almost all standard containers behave this way (again, in my experience)
source to share
The EJB container will bind local and remote interfaces with different JNDI names, so it depends on which one you are viewing. For example, in EJB 3.1, the default binding location would be something like this:
java:app/YourEJBModule/YourEJBName!com.your.pkg.LocalInt
java:app/YourEJBModule/YourEJBName!com.your.pkg.RemoteInt
source to share
The EJB 3.1 specification in section 3 clearly explains local and remote views. Section 3.3.2 says:
Session beans can have local clients. A local client is a client that sits in the same JVM with a session bean, that the local client provides, and that can be tightly coupled to the bean. the local client of the session bean can be another enterprise bean or a website bean. Accessing an enterprise bean through a local client view requires collocation in the same JVM of both the local client and the enterprise bean that provides the local client view. The local client view therefore does not provide the location transparency provided by the remote client view. Access to the enterprise bean through the local client view is only required to support local clicks, packaged in the same application as the enterprise bean that provides the local client view.Conforming implementations of this specification may optionally support access to a local client enterprise view bean from the local client, wrapped in another expression.
This should explain the behavior
source to share