-
1. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
kwintesencja Sep 4, 2012 8:19 AM (in response to banzeletti)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)
banzeletti Sep 6, 2012 7:24 AM (in response to kwintesencja)The @Stateful Bean
@Stateful
public class PersonService implements
Serializable {
...
@Inject @PersonDatabase
private EntityManager personDB;
...
//Business Method
public
List<Person> getAllPersons() {List<Person> result = null
TypedQuery<Person> tq =
personDB.createNamedQuery("getAll", Person.class);result = tq.getResultList();
return result;
}
The @Producer
public
class
JEEAdapter {@PersistenceContext(type=PersistenceContextType.EXTENDED)
...
@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() {
-
3. Re: HOWTO @Inject a @PersistenceContext(Type=EXTENDED)
kwintesencja Sep 6, 2012 12:50 PM (in response to banzeletti)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)
banzeletti Sep 6, 2012 4:52 PM (in response to kwintesencja)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
Bernhard