4 Replies Latest reply on Nov 9, 2010 1:43 PM by wangliyu

    Many jars, beans.xml in all of them?

    ljnelson

      Hello; thank you for a great product.


      I had a question about how many META-INF/beans.xml files I need in a multi-jar scenario.  I'm using Weld as integrated into Glassfish 3.1.


      Specifically, I have an EJB jar with a bean class in it that implements an interface.  The interface is in another jar.


      Do I need META-INF/beans.xml files in both archives?  If I only include one (in the EJB jar), Glassfish gets angry.  I'm unclear as to whether this is a bug or a misreading of the specification.


      Thanks,
      Laird

        • 1. Re: Many jars, beans.xml in all of them?
          wangliyu

          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 requires by 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.

          • 2. Re: Many jars, beans.xml in all of them?
            ljnelson

            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:



            1. 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.

            2. 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.)

            3. 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.


            Best,

            Laird

            • 3. Re: Many jars, beans.xml in all of them?
              wangliyu

              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.

              • 4. Re: Many jars, beans.xml in all of them?
                wangliyu

                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.


                Typical scenario:
                automatically logout user when shutdown app server, POJO are good in this case.