CDI (Weld) + DeltaSpike + Converstation

Question

I'm currently trying to get CDI (Weld to be more precise) to work with JSF 2 and a long running conversation. I'm starting the conversation in @ConversationScoped my backing bean. I'm also creating a @ConversationScoped entity manager. Sadly the entity I'm editing in my backing bean always get's a LazyInitializationException when JSF is trying to write a @ManyToMany mapped field. It seems that the entity get's detached from the entitymanager. In my EntityManagerProducer (see below) the method createEntityManager() is not called bevore the LazyInitializationException is thrown, so I'd assume that the entitymanager is actually session scoped. But from what I understand my code does not generate an extended persistence context (since I could not figure how to do that programmatically).

As far as I know DeltaSpike does not yet offer anything for dealing with long running conversations in JSF. Can anybody suggest a method on how to implement long running conversations with CDI using Weld + DeltaSpike (preferably on a Tomcat with weld-servlet)?

@ApplicationScoped
public class EntityManagerProducer {
    @Inject
    @PersistenceUnitName("myUnit")
    private EntityManagerFactory emf;

    @Produces
    @ConversationScoped
    public EntityManager createEntityManager() {
        return emf.createEntityManager();
    }

    public void closeEm(@Disposes EntityManager em) {
        em.close();
    }
}

Answer 1

The lazy initialization exception actually does not come from extended persistence contexts or CDI or DeltaSpike. It's simply the same behaviour as described here: selectManyCheckbox LazyInitializationException on process validation

JSF 2 clones the PersistentBag of my entity causing it to get detached. I also worked around by sprinkling lot's of

<f:attribute name="collectionType" value="java.util.ArrayList" />

throughout my JSF code.

Answer 2

Having the EntityManager in a conversation scope is only one side of the equation, what scope are your entities in ?

In order to avoid detaching the entities they should also be conversation scoped.

As a side note : I found that instead of dealing with entities in a long running scope , it is much easier to reattach them in each request scope.