[cdi-dev] Support Request (and Conversation?) Scope in @Singleton @Startup @PostConstruct methods

Pete Muir pmuir at redhat.com
Wed Mar 7 12:30:06 EST 2012


I'm not necessarily disagreeing with you ;-)

On 7 Mar 2012, at 17:27, Mark Struberg wrote:

>>> @ConversationScoped EntityManager is broken, broken, broken. The EM is per 
>> JPA spec NOT Serializable and thus must not get stored in the Session.
>>> There are some impls which _are_ Serializable, but those are not JPA spec 
>> compliant (e.g. avajé eBean). With the mandatory support of locking and 
>> pessimistic locking it is just technically impossible to implement a 
>> Serializable EntityManager.
>> 
>> You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code 
>> to deal with entities being properly propagated - basically imposing 
>> serialisation above the JVM layer) and I know the JBoss Clustering team are 
>> looking at this. But it is a vendor specific solution only.
>> 
> 
> 
> Well, I know that there is some Hibernate mode which supports some serialization but in this mode 
> 
> .) it is not JPA compliant anymore
> .) you will loose the 'state' of the entities after the serialisation
> .) this was only JPA1
> .) you will loose all pessimistic locks
> .) it's not portable 
> 
> 
> I still think that detaching after each request and merging it the next time works best for an EE 6 app.
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Mark Struberg <struberg at yahoo.de>
>> Cc: Guido Bonazza <guidbona at yahoo.com>; "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 5:38 PM
>> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton @Startup @PostConstruct methods
>> 
>> 
>> On 6 Mar 2012, at 13:58, Mark Struberg wrote:
>> 
>>> 
>>> 
>>> Folks, again and again and again: 
>>> 
>>> 
>>> @ConversationScoped EntityManager is broken, broken, broken. The EM is per 
>> JPA spec NOT Serializable and thus must not get stored in the Session.
>>> There are some impls which _are_ Serializable, but those are not JPA spec 
>> compliant (e.g. avajé eBean). With the mandatory support of locking and 
>> pessimistic locking it is just technically impossible to implement a 
>> Serializable EntityManager.
>> 
>> You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code 
>> to deal with entities being properly propagated - basically imposing 
>> serialisation above the JVM layer) and I know the JBoss Clustering team are 
>> looking at this. But it is a vendor specific solution only.
>> 
>>> 
>>> 
>>> 
>>>>>    Moreover, quoting https://issues.jboss.org/browse/CDI-148 
>> ("There is 
>>>> no reason why the ConversationScope should be any less available than 
>> the 
>>>> RequestScope"),
>>> Well, there is a difference between a Servlet-Request and a JSF-Request. 
>> The difference is subtle but important. The JSF-Request is e.g _not_ available 
>> in some ServletFilters which are outside of the JSFs FacesServlet handling. The 
>> CDI spec states this in 6.7.4:
>>> 
>>>> If the conversation associated with the current JSF request is in the 
>> transient state at the end of a JSF request,
>>>> it is destroyed, and the conversation context is also destroyed. 
>>> 
>>> But the Request Context lives much longer! It will also be available in 
>> various ServletFilters and Listeners. Thus the statement is not entirely 
>> correct.
>> 
>> I think the statement is one of intent, not state. I.e. there is no reason it 
>> should be less available.
>> 
>>> 
>>> 
>>>> to be allowed to use it @Singleton @Startup @PostConstruct methods.
>>> Of which Beans are you talking here? EJBs? CDI managed beans? Which 
>> @Singleton annotation? the one from JSR-330 or EJB?
>>> 
>>> Please also note that the JSR-330 @Singleton is imo completely useless 
>> because it's underspecified. "Singleton" in which _context_? 
>>> 
>>> 1 per WebApp?
>>> 
>>> 1 per EAR?
>>> 1 per JVM?
>>> 1 per Cluster?
>>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> ----- Original Message -----
>>>> From: Pete Muir <pmuir at redhat.com>
>>>> To: Guido Bonazza <guidbona at yahoo.com>
>>>> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>>>> Sent: Tuesday, March 6, 2012 10:30 AM
>>>> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in 
>> @Singleton @Startup @PostConstruct methods
>>>> 
>>>> Please file a CDI issue :-)
>>>> 
>>>> On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
>>>> 
>>>>>    Hello everyone!
>>>>>    Checking out the CDI 1.0 spec and actually trying it on JBoss AS 
>>>> 7.1.0.Final it seems to me that the Request Scope is not active in 
>> @Singleton 
>>>> @Startup @PostConstruct method, so I'd like to propose this use 
>> case to be 
>>>> supported in the next version of CDI.
>>>>>    Moreover, quoting https://issues.jboss.org/browse/CDI-148 
>> ("There is 
>>>> no reason why the ConversationScope should be any less available than 
>> the 
>>>> RequestScope"), I think that conversation scope should be 
>> available too in 
>>>> this context. It would be very useful, for example, when you have an 
>>>> EntityManager produced in conversation scope (mostly used in JSF 
>> contexts), to 
>>>> be allowed to use it @Singleton @Startup @PostConstruct methods.
>>>>>    Of course there should be some limitations in this case (long 
>> running 
>>>> conversation promotion shouldn't be allowed for example), but the 
>> basic case 
>>>> should be supported in my opinion.
>>>>> 
>>>>>    Thanks for the attention,
>>>>>        Guido
>>>>> 
>>>>>    _______________________________________________
>>>>>    cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 




More information about the cdi-dev mailing list