9 Replies Latest reply on Dec 29, 2009 6:43 PM by John Ament

    Extensions and conflicts in producer methods

    alberto Gori Novice

      I was wandering, If I write a CDI extension where I have this producer


      @Produces @RequestScoped FacesContext getFacesContext() {
          return Facescontext.getCurrentInstance();
      }
      



      so that I can write my extension more easily, and tomorrow Weld or some other extension introduces the same idea, what happen?
      I think we get a conflicts and my extension is no more usable with the other one.


      Can CDI and Weld solve this issue?

        • 1. Re: Extensions and conflicts in producer methods
          alberto Gori Novice

          FacesContext injection is only an utility (the injection is not supposed to be used outside the extension, I mean developers shouldn't use it).
          I need something to say that this producer is valid only inside this package or jar.

          • 2. Re: Extensions and conflicts in producer methods
            John Ament Master

            Limiting injection to a particular module is not supported, as far as I am aware.  However, you could qualify it a bit further (since unqualified injection seems like a really bad idea).




            @Produces @RequestScoped @AlbertoFaces FacesContext getFacesContext() {
                return FacesContext.getCurrentInstance();
            }



            • 3. Re: Extensions and conflicts in producer methods
              Gavin King Master

              If you annotate your producer method @Alternative, it will be used only by modules which explicitly enable that alternative. And it would be used in preference to any other non-alternative bean. Read spec sections 5.1-5.2.1.

              • 4. Re: Extensions and conflicts in producer methods
                Gavin King Master

                John Ament wrote on Dec 29, 2009 16:26:


                Limiting injection to a particular module is not supported, as far as I am aware. 


                That's not right. Please read spec section 5.1, titled Modularity.

                • 5. Re: Extensions and conflicts in producer methods
                  John Ament Master

                  Gavin King wrote on Dec 29, 2009 18:00:


                  That's not right. Please read spec section 5.1, titled Modularity.


                  Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?

                  • 6. Re: Extensions and conflicts in producer methods
                    Gavin King Master

                    John Ament wrote on Dec 29, 2009 18:06:



                    Gavin King wrote on Dec 29, 2009 18:00:


                    That's not right. Please read spec section 5.1, titled Modularity.


                    Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?


                    An alternative defined in one module X may be used by any other module that has X in its classpath.

                    • 7. Re: Extensions and conflicts in producer methods
                      Gavin King Master

                      Gavin King wrote on Dec 29, 2009 18:11:



                      John Ament wrote on Dec 29, 2009 18:06:



                      Gavin King wrote on Dec 29, 2009 18:00:


                      That's not right. Please read spec section 5.1, titled Modularity.


                      Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?


                      An alternative defined in one module X may be used by any other module that has X in its classpath.


                      But every module that uses X must explicitly declare it in beans.xml, or course.

                      • 8. Re: Extensions and conflicts in producer methods
                        alberto Gori Novice

                        Gavin King wrote on Dec 29, 2009 17:59:


                        If you annotate your producer method @Alternative, it will be used only by modules which explicitly enable that alternative. And it would be used in preference to any other non-alternative bean. Read spec sections 5.1-5.2.1.


                        Ok thanks. CDI is amazing!

                        • 9. Re: Extensions and conflicts in producer methods
                          John Ament Master

                          Gavin King wrote on Dec 29, 2009 18:12:



                          Gavin King wrote on Dec 29, 2009 18:11:



                          John Ament wrote on Dec 29, 2009 18:06:



                          Gavin King wrote on Dec 29, 2009 18:00:


                          That's not right. Please read spec section 5.1, titled Modularity.


                          Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?


                          An alternative defined in one module X may be used by any other module that has X in its classpath.


                          But every module that uses X must explicitly declare it in beans.xml, or course.



                          Right, this is sort of what I was alluding to.  As a result, even if your bean archive used an alternative, there's nothing stopping my bean archive from using it (I just need to configure it appropriately).