If EJB exposed @Remote interface, but you inject the EJB bean instead of its Remote interface, will this trigger a remote or local invocation?

Question

I have a EJB bean that exposed to two interface like below: Local interface is for my web app, and Remote interface is for my App Client

@Stateless
public class CoreMainEJB implements CoreMainEJBRemote, CoreMainEJBLocal {
    //...
}

so my App Client looks as below. Remote method invocation is happened in this case

public class Main {
   @EJB
   private static CoreMainEJBRemote coreEJBRemote;

   public static void main(String[] args) {
        coreEJBRemote.process(args[0]);       
   }
}

From my web app I invoke as below. Local method invocation is happened in this case

@ManagedBean
@RequestScoped
public class DisplayInbound {
    @EJB
    private CoreMainEJBLocal coreMainEJBLocal;

    public void processPackages() {
        coreMainEJBLocal.process(...);   
    }
}

So here is my question, If the EJB only exposed @Remote interface, but in your web app, you inject the EJB bean directly instead of its Remote interface, will this trigger a remote invocation or local invocation? For example:

@Stateless
public class CoreMainEJB implements CoreMainEJBRemote{
    //...
}

and in the web app, I do this

@EJB
private CoreMainEJB coreMainEJB;

public void processPackages() {
    coreMainEJB.process(...);   //Is this local or remote invocation here?
}

Answer 1

The last example as given will simply not work. Since CoreMainEJB already implements a remote interface, the container will not create a No-Interface view. This is exactly the case for which @LocalBean is intended.

So to answer the question 'Is this local or remote invocation here?' directly: it's neither. The container will not be able to inject anything and probably barf out at the deployment stage.

If you define your bean as:

@Stateless
@LocalBean
public class CoreMainEJB implements CoreMainEJBRemote{
    //...
}

Then local semantics will apply here:

@EJB
private CoreMainEJB coreMainEJB;

public void processPackages() {
    coreMainEJB.process(...);   // Local semantics
}

(assuming the above code fragment is in the same application as where CoreMainEJB is defined of course)