@Stateless @LocalBean not discovered as a CDI Bean

[dabloem]

When adding an @Observer method to a @Stateless bean, you have to annotate with @LocalBean. However, then the stateless bean is not discovered as a CDI bean anymore.

see cdi-test/CreditCardProcessor.java at master · dabloem/cdi-test · GitHub  and the arquillian test  cdi-test/PaymentProcessorTest.java at master · dabloem/cdi-test · GitHub .

Any idea why the Stateless bean is not a CDI bean anymore after annotating with @LocalBean?

Regards,

Duncan

[mkouba]

Hi Duncan,

first of all you don't have to annotate the SLSB with @LocalBean. For  a session bean, the observer method must be either a business method (i.e. declared on the PaymentProcessor in your case) or a static method (see also 10.4. Observer methods). Also the SLSB is still discovered even if annotated with @LocalBean but if it has a no-interface view the set of bean types only contains bean class, all superclasses and java.lang.Object (see also 3.2.2. Bean types of a session bean). So it does not contain PaymentProcessor in your case.

[dabloem]

Hi Martin,

But if neither options (business method or static) are possible, annotation with @LocalBean seems reasonable, even though it has/contains a PaymentProcessor interface (see example).

Also, it works on JBoss AS 7.1.1.  I don't think this is spec related (CDI 1.0 vs 1.1), but I could be wrong.

Thanks, Duncan

[mkouba]

If you annotate an SLSB with @LocalBean the container thinks it exposes a no-interface view, i.e. the onObserve() method becomes a business method and it's recognized by CDI as an observer. However, the set of bean types of your SLSB only contains CreditCardProcessor and java.lang.Object (this is per the spec). And so Instance<PaymentProcessor> should be an unsatisfied dependency (unless there's another bean with type PaymentProcessor).

[mkouba]

Also, it works on JBoss AS 7.1.1.

This is odd. Let me try your cdi-test...

[mkouba]

Duncan, I did a quick test and you're right in that it works differently on AS7/EAP with Weld 1.1.x. Most probably because there is no proper TCK test for this. In any case, I believe that the current implementation (Weld 2.2+) is correct per the spec and will likely not change.