for any jars that contain CDI components (Bean, Interceptor...), you need to put the bean.xml in the META-INF/, so if you have EJB interface in one jar and classes in another jar, only the classes jar need bean.xml, the interface is not the Weld component, it just
requiresby EJB container (actually, EJB3.1 or GF3.1 doesn't require the interfaces anymore for local EJB, plus you should not separate the interface and classes into 2 different jars, some APP server will report warning or error).
If both jars have CDI components, you should put bean.xml in both jars.
Wang Liyu wrote on Nov 09, 2010 11:11:
for any jars that contain CDI components (Bean, Interceptor...), you need to put the bean.xml in the META-INF/, so if you have EJB interface in one jar and classes in another jar, only the classes jar need bean.xml, the interface is not the Weld component,
Thank you. (I am sharing interfaces according to the Java EE specification; specifically the interface jars are going in my .ear file's lib directory, so compliant application servers will not complain.) My takeaway here:
- Interfaces are not CDI components. Consequently, if a jar contains only interfaces, it does not need a beans.xml file to play nicely in a CDI environment.
- Even though an interface is a CDI
type, a compliant application server should be able to infer such types implemented by a CDI bean without the presence of a beans.xml. (Glassfish did not used to do this; I am not sure if it does it now.)
- beans.xml descriptors in EJB jars are required, in order to have those EJBs automagically available via @Inject, even though what's being injected is often the interface that the bean implements.
If all of this is correct, then I think I understand now. Thank you.
Interfaces are part of the Bean, itself is not a Bean, CDI or EJB container requires it in the class path (for cast or generate the proxy classes, so and so on), but you don't need beans.xml with it.
beans.xml is only required to tell CDI that the jar contains some CDI components.
CDI beans doesn't really need interfaces as type, Bean's type can be interfaces, abstract class, or normal class (without final key word). so too simplify you app, you should be able to remove the interfaces.
Sometimes POJO are OK.
Also one problem I encounter with EJB is when shutdown the app server, CDI try to dispose/destroy the bean instances, depends on the app server you choose, you may get trouble, for example, JBoss shutdown EJB container already, and CDI try to call SFSB's destroy method, and you will get exceptions.
automatically logout user when shutdown app server, POJO are good in this case.