JNDINames are different for the local and remote interface.
The application will have to decide between the local and remote interface through the JDNIName.
What if I use @EJB injection of the interface on the caller?
the only thing i found in Spec. to this is that lookups are performed in the referencing bean's java:comp/env namespace.
When local and remote interface is identical and the local interface is "registered" with a SB in the current application server i think it make no sense to inject the remote version. Because the injection is analysed in the AS, it would (in my mind) first check if the interface is used somewhere as LocalInterface. If not it would use the remote.
So I am sure JBoss will inject the local.
After some tests, it seems you are wrong.
I had a call to a session bean method explicitly through an interface that was annotated as @Local. The call passed a non-serializable Entity bean as a parameter. This worked OK. (Caller and callee are part of the same application and are in the same JAR, in the same EAR, in other words, a local call is possible).
However, when I added the @Remote annotation, I started getting a NonSerializableException. Serialization is only needed for the Remote call. Therefore, when I have both annotations it seems that @Local is just ignored, at least on JBoss.
Someone from the JBoss team cares to answer if this is the expected behavior or if we have a bug here?
I thnik @Remote has priority over @Local but this is an implementation detail.
I kinda think having both annotations on the same interface is a code smell.
Transparent remote invocation is a myth, and "clients" should be aware of what they are doing
If you use JBossSerialization on remoting layer you could have non serializable objects being serialized.
sorry.. i was wrong.. you get a RemoteProxy to the SB.
an interface cannot be both a @Remote and @Local at the same time. it is illegal in the specification. The reason?
@EJB SomeINterface foo;
the container would not know if you were referencing a remote or local interface.
If it is illegal, shouldn't I get an error (or at least a warning) when I compile (or at least deploy)?
After all, one of the reasons we use Java is not to shoot ourselves on the foot. ;)