4 Replies Latest reply on Sep 6, 2012 4:52 PM by Bernhard Anzeletti

    HOWTO @Inject a @PersistenceContext(Type=EXTENDED)

    Bernhard Anzeletti Newbie

      Dear Community,

      I would like to keep my Entity Manager alive across a whole conversation. When I use, say, a SFSB with a @PersistenceContext(Type=Extended) field, everything works as I understand it should work. However, if I @Inject the PersistenceContext (letting it be @Produced by a producer field in another bean) it breaks up (even though in case the Type is not extended, it still works as I understand it should work. It is just the "type=EXTENDED" annotation attribute that creates a surprising result).

      Did I get something wrong?

      Kind regards


        • 1. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
          Rafael Pestano Novice

          Hi bernhard,


          how is your producer? can you share the bean which is producing the EM and the bean where you're trying to inject it?

          • 2. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
            Bernhard Anzeletti Newbie

            The @Stateful Bean



            public class PersonService implements

            Serializable {



            @Inject @PersonDatabase 


            private EntityManager personDB;



            //Business Method




            List<Person> getAllPersons() {

            List<Person> result = null

            TypedQuery<Person> tq =

            personDB.createNamedQuery("getAll", Person.class);

            result = tq.getResultList();

            return result;





            The @Producer






            JEEAdapter {


            private EntityManager em;






            @Produces @PersonDatabase






            The Problem: an EJB Exception ...


            Caused by: java.lang.NullPointerException
            at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createNamedQuery(EntityManagerWrapper.java:566)
            at com.anbern.base.service.PersonService.getAllPersons(PersonService.java:52)


            Note that the EntityManager in the @Stateful bean is not null, SOMETHING gets injected. Maybe the Wrapper proxy does not keep state of its internal EntitManager? (Just guessing....)


            EntityManager getEntityManager() {


            return em;

            • 3. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
              Rafael Pestano Novice

              i think you have to turn your producer in a Stateful EJB otherwise you wont get the persistenceContext.


              Also your PersonService dont need to be an EJB(but can be) cause the PersistenceContext will be managed by the producer bean.

              • 4. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
                Bernhard Anzeletti Newbie

                Dear Rafael,


                thank you for taking time and helping me out. I expect your solution to work.


                On further consideration, who is going to manage the life cycle of the Producer SFSB? I think the only valid answer to this question is that it should be the bean the em gets injected into, which is supposed to support long-running conversations (SFSB als "client state representation" on the server). So I benefit from the CDI uniformness using the @Inject with the cost of managing two different SFSB with exactly the same life cycle. This seems to me much more difficult than to simply use the @PersistenceContext annotation in the original SFSB and keeping the equation "One Long Running Conversation = excactly one SFSB instance" balanced (ths equation follows from the gui paradigm, which is supposed to resemble eclipse's workbench: Basically a "tree view" and possible many open editors on individual items on the tree, each represented by its own long-running conversation/SFSB).  I am really confused about the proper use of SFSB "vs" long-running conversations. I believe that conversations and SFSB both claim nearly identical territory.


                I agree that there is possibly not much more to the conversation support than keeping the em, and I think the further proceeding depends much on the validation of this assumption.


                Did I get something wrong conceptually? What's your point of view?


                Knd regargs