Question

So far, I almost always worked with no-interface EJBs and have a slight understanding about the need of @Local annotation. Consider this example:

public interface MyBeanIntf { void doStuff(); }

@Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }

Should the MyBeanIntf be marked as @Local? I don’t see any benefit from that, because even when I don’t annotate it as @Local, I still can use DI to properly inject it into UI Controller:

@Named
@SessionScoped
public class TestController implements Serializable {

  // injection works perfectly, even when MyBeanIntf is not marked as @Local
  @Inject
  private MyBeanIntf myBean;

  // or even like this:
  // @EJB
  // private MyBeanIntf myBean;

}

Let’s make it more complex:

public interface MyBeanIntf { void doStuff(); }
public class MySuperBean implements MyBeanIntf { public void doStuff() { } }

@Stateless
public class MyBean extends MySuperBean { }

Is MyBean now considered a valid Local EJB bean? I have some doubts because it implements the interface indirectly.

Answer 1

If your EJB implements some interface but you don’t specify (neither on the EJB nor the interface itself) which interface it is (@Remote, @Local) than it’s assumed that it’s a @Local one.

Therefore your code:

public interface MyBeanIntf { void doStuff(); }

@Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }

is semantically identical to the following:

@Local
public interface MyBeanIntf { void doStuff(); }

@Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }

When it comes to the second part of your question, I think that section 4.9.2.1 Session Bean Superclasses from EJB 3.1 FR spec would be interesting for you. From my understanding (so it might not be correct), it seems that your bean should not be considered as exposing a valid Local interface because of the following excerpt:

@Stateless
public class A implements Foo { ... }

@Stateless
public class B extends A implements Bar { ... }

Assuming Foo and Bar are local business interfaces and there is no
associated deployment descriptor, session bean A exposes local
business interface Foo and session bean B exposes local business
interface Bar, but not Foo.

Session bean B would need to explicitly include Foo in its set of
exposed views for that interface to apply.

Update:

As an addition one more excerpt from the spec:

A session bean class is permitted to have superclasses that are
themselves session bean classes. However, there are no special rules
that apply to the processing of annotations or the deployment
descriptor for this case. For the purposes of processing a particular
session bean class, all superclass processing is identical regardless
of whether the superclasses are themselves session bean classes.