5 Replies Latest reply on Apr 14, 2009 1:36 PM by nickarls

    Seam Managed Persistence Context in WebBeans

    hajdi

      In order to exploit full potential of conversation model Seam provides conversation scoped Seam Managed Persistence Context which is simpler to use than error prone EJB PersistenceContext propagation rules.


      Currently in Seam conversation scope seems to be available even in non JSF requests so you can use SMPC even in MDBs or EJB executed from EJB Timer Service (although there is an old and unsolved issue that is mentioned on Seam forum thread that makes it unusable).


      In WebBeans however according  to section Built-in scopes of Web Beans Reference Documentation conversation context is not active during non-JSF invocations like remote EJB or MDBs calls and ContextNotActiveException is thrown if conversation scoped component is accessed in such invocations.


      Is it already planned how SMPC will be implemented in WebBeans? Or maybe there will be some EJB 3.1 level improvement in this area?

        • 1. Re: Seam Managed Persistence Context in WebBeans
          pmuir

          I haven't got detailed plans, but we will certainly implement the SMPC for Web Beans.


          BTW the spec doesn't actually say that the conversation context must not be active during non-JSF invocations, just that it is not active by default then.

          • 2. Re: Seam Managed Persistence Context in WebBeans
            hajdi

            So possible WebBeans based SMPC implementation has the potential to be unportable to different JEE6 servers then. That would be pity.


            I am wondering whether SMPC is the right solution for non-JSF based invocation at all. What do you think? I like SMPCs in JSF driven conversational components and would like to keep using them everywhere else. Especially that such non-JSF invocated components are often also used by conversation components and should share same SMPC. In Seam this issue stops me from doing this and in WebBeans/JEE6 it has the potential to be not portable. Am I missing something here?


            BTW. No body responded to this issue. Is it really a bug? It seems strange to me that such a major problem exists in Seam SMPC for so long time. Do you think that solution provided in thread can be considered a fix?

            • 3. Re: Seam Managed Persistence Context in WebBeans
              pmuir

              Rafal Hajdacki wrote on Apr 06, 2009 16:09:


              So possible WebBeans based SMPC implementation has the potential to be unportable to different JEE6 servers then. That would be pity.


              Whilst it may have that potential, we will design it so this limitation doesn't exist.


              I am wondering whether SMPC is the right solution for non-JSF based invocation at all. What do you think? I like SMPCs in JSF driven conversational components and would like to keep using them everywhere else. Especially that such non-JSF invocated components are often also used by conversation components and should share same SMPC. In Seam this issue stops me from doing this and in WebBeans/JEE6 it has the potential to be not portable. Am I missing something here?


              I would still use an SMPC - the Seam 3 SMPC will be portable, despite your fears :-).


              BTW. No body responded to this issue. Is it really a bug? It seems strange to me that such a major problem exists in Seam SMPC for so long time. Do you think that solution provided in thread can be considered a fix?


              The issue is scheduled for Seam 2.2.0 - that seems like a response to me :-) File a patch, we can look sooner then.

              • 4. Re: Seam Managed Persistence Context in WebBeans
                gonorrhea

                Pete Muir wrote on Apr 06, 2009 15:18:


                I haven't got detailed plans, but we will certainly implement the SMPC for Web Beans.


                would you rather call it WBMPC?

                • 5. Re: Seam Managed Persistence Context in WebBeans
                  nickarls

                  JCDIMPC, better known as J5C ;-)