1 2 Previous Next 23 Replies Latest reply on Apr 3, 2013 11:25 AM by Tang Yong Go to original post
      • 15. Re: Infinispan 5.1.2 and Glassfish 3.1.2
        Tang Yong Newbie

        Deeply, current my investigation status is as following:


        After I debugged JBOSS 7.1.1.Final(it uses weld-core-1.1.5.AS71.Final),

        I found that in org.jboss.weld.bootstrap.Validator class 273,


        Set<?> resolvedBeans =



        While ij is "@Inject private



        resolvedBeans is "[Producer Method [EmbeddedCacheManager] with

        qualifiers [@Any @Default] declared as [[method] @Produces

        @ApplicationScoped public

        com.mycompany.Config.defaultEmbeddedCacheManager()]]" and this is right.


        However, in  Glassfish (it uses weld-core-1.1.8.Final), the

        above resolvedBeans is empty.


        That is to say, Glassfish has not found the right Producer

        Method from the ear's ejb jar.

        • 16. Re: Infinispan 5.1.2 and Glassfish 3.1.2
          Kevin Pollet Newbie



          First, thanks for looking into that :-)


          I didn't remember what was my conclusion. I vaguely remember something weird with glassfish CDI injection between two bean archives.

          Maybe you can test that by having a producer in a separate bean achive and inject the produced bean in another bean achive ?


          Hope this help

          • 17. Re: Infinispan 5.1.2 and Glassfish 3.1.2
            Tang Yong Newbie



            Thanks your reply.


            Yes, I now am confirm whether in gf, classes in ear's /lib jars with beans.xml can not resolve beans from ear's ejb jar or not?

            If being such a case, this should be an *visibility* issue of gf.


            CDI injection should allow ear/lib accesses beans from ear's ejb or war.




            • 18. Re: Infinispan 5.1.2 and Glassfish 3.1.2
              Tang Yong Newbie

              Kevin, Kovac


              I have made an experiment(a general scene) and confirmed that the same issue happened.



              classes in ear's /lib jars with  beans.xml can not resolve beans from ear's ejb jar(maybe war is the same as ejb).



              This is not related to Infinispan-CDI and Infinispan-Core and should be gf weld integration issue while handling JavaEE Injection.


              I have asked gf cdi team to judge whether the issue is bug.


              If being a bug, I think that before v4 is released, this should be fixed.



              --Tang Yong

              • 19. Re: Infinispan 5.1.2 and Glassfish 3.1.2
                Tang Yong Newbie

                For glassfish, we need to do a workground by adjusting ear's structure in order to make ear' lib's jar access produce method from another jar.


                The attachment has been deployed and ran into glassfish successfully. Pl. seeing it and based on it, you can make an adjustment for your infinispan sample.

                • 20. Re: Infinispan 5.1.2 and Glassfish 3.1.2
                  Kevin Pollet Newbie

                  Nice :-)


                  Can you explain the workaround?



                  • 21. Re: Infinispan 5.1.2 and Glassfish 3.1.2
                    Tang Yong Newbie

                    Hi Kevin,


                    OK, I want to say the background about glassfish ear deployment,



                    While an user's ear is created with the following structure,




                      |     |----jar1(with beans.xml)

                      |     |----jar2(common jar without beans.xml)

                      |     |----jar...


                      |---ejb(with beans.xml)


                    This is not an uncommon ear, however, while jar1 has an class which has an inject point,




                    class A


                       @inject BInf b      --->BInf is an interface




                    And ejb has an class which has a produce method to provide a BInf's implementation,




                    class Ejb



                        public BInf defaultBImpl() {





                    Then, while deploying such an ear into Glassfish v3.1.2.2, we will see the "WELD-001408 Unsatisfied dependencies".



                    Glassfish team ever discussed such a similar scene:  whether ear's lib can access ejb or war's classes?

                    The result is that JavaEE spec has not clearly specified ear's lib must access ejb or war's classes.


                    About whether the result is reasonable, I think that let us leave the topic to JavaEE spec expert group,


                    Apparently, Glassfish has not allowed  ear's lib can access ejb or war's classes , so while Weld tries to validate whether having any dependency can

                    meet " @inject BInf b", although ejb's produce method is there,  "WELD-001408 Unsatisfied dependencies" still happened.


                    [Extending the background]

                    If you looked into the infinispan cdi sample with ejb carefully, you will see the sample's design is the same as the above background.



                    In theory, I think that three workarounds should be considered,


                    1. integrate infinispan into Glassfish

                    As a future consideration, If I have more time, I want to do it, because Infinispan is a greate datagrid framewok and in the future, should be jsr347's RI.


                    2. make ejb's produce method out of ejb and create a new jar

                    The attachment from the previous thread is just the solution. Concretely, I create a new ear's structure as following:



                      |     |----jar1(with beans.xml)

                      |     |----jar2(common jar without beans.xml)

                      |     |----jar3(with beans.xml and having produce method)


                      |---ejb(with beans.xml)


                    jar3 is created for having a produce method to meet jar1's injection point and ejb has removed produce method.


                    Thus, while deploying the new ear into gf, because jar1 can access jar3, deploying will be successful.


                    3. put jar1 into ejb

                    For infinispan's sample, I think that this is not a good solution because, maybe infinispan should be shared with WAR or another EJB.


                    Of course, if having more solutions, I want to listen to them very much!



                    --Tang Yong

                    • 22. Re: Infinispan 5.1.2 and Glassfish 3.1.2
                      Gregor Kovač Newbie

                      With the help from Tang I finally made it work.


                      I still have to make it work in my main application with lots of maven modules, jars, classes, ....

                      • 23. Re: Infinispan 5.1.2 and Glassfish 3.1.2
                        Tang Yong Newbie






                        1 2 Previous Next