EJB 3.1. Does @Local need an annotation?

Question

Until now, I almost always worked with EJB without an interface, and was a little versed in the need for @Local annotation. Consider this example:

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

Should MyBeanIntf be marked as @Local ? I do not see any benefit from this, because even when I do not comment on it as @Local , I can still use DI to correctly enter it into the user interface 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; } 

Make it harder:

 public interface MyBeanIntf { void doStuff(); } public class MySuperBean implements MyBeanIntf { public void doStuff() { } } @Stateless public class MyBean extends MySuperBean { } 

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

Answer 1

If your EJB implements any interface, but you do not specify (neither the EJB, nor the interface itself) which interface it is (@Remote, @Local), than it suggested that it is @Local.

Therefore your code:

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

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 will be interesting for you. From my understanding (so that this may be wrong), it seems that your Bean should not be construed as exposing a valid local interface due to the following passage:

 @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, the Bean session exposes the local Foo business interface and the Bean B session provides the local business interface, but not Foo .

The Bean B session will need to explicitly include Foo in its set of open views for this interface.

Update:

In addition, another excerpt from the specification:

A Bean session series is allowed to have superclasses that are Bean sessions themselves. However, there are no special rules that apply to processing annotations or deploying a descriptor for this case. In order to handle a particular session Bean class, all processing of the superclass is identical regardless of whether the superclasses themselves are Bean classes.