<div dir="ltr">Yes, really good point : Extended Persistence Context....<div><br></div><div>Hum....</div><div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 28, 2014 at 5:45 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">you surely forgot a detail only @Stateful handle: extended PC. That's<br>
where stateful makes sense and @Transactional doesn't help. Then there<br>
is nowhere else ATM where passivation is defined (even not in CDI with<br>
passivable things). Do you plan to specify it in CDI?<br>
<span class="im HOEnZb"><br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">2014-12-28 17:42 GMT+01:00 Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>>:<br>
> I should have explained my PoV a bit better. I'm trying to take the EJB<br>
> services, extract them, see if they could benefit for other components, if<br>
> yes, in which spec could they go.<br>
><br>
> Today, there is less and less difference between :<br>
><br>
> @Stateful<br>
> @SessionScoped<br>
> public class MySessionBean {<br>
> @PersistenceContext<br>
> EntityManager em;<br>
> ...<br>
> }<br>
><br>
> And :<br>
><br>
> @Transactional<br>
> @SessionScoped<br>
> public class MySessionBean {<br>
> @PersistenceContext<br>
> EntityManager em;<br>
> ...<br>
> }<br>
><br>
> So I wonder if it would make sense to bother with @PostActivate,<br>
> @PrePassivate. I could see the benefit of @Remove though.<br>
><br>
> Antonio<br>
><br>
><br>
> On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> EJBs work off of a pool of objects and these life cycle methods are<br>
>>> typically used (from the use cases I've dealt with them) to initiate or<br>
>>> destroy some end user data for the context in which they are used.<br>
>><br>
>><br>
>> @PrePassivate/@PostActivate are used with @Stateful beans, which being<br>
>> unique instances are far less likely to be pooled. Pools are mostly used for<br>
>> @Stateless beans (if pools are used at all, the spec doesn't mandate those).<br>
>><br>
>> Kind regards,<br>
>> Arjan Tijms<br>
>><br>
>><br>
>>><br>
>>><br>
>>> I think you might be thinking of PostConstruct/PreDestroy which match to<br>
>>> the CDI/ManagedBean paradigm better. There's no pool of these objects<br>
>>> around, they simply get created and destroyed when done. For each of the<br>
>>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do<br>
>>> the same thing.<br>
>>><br>
>>> John<br>
>>><br>
>>> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves<br>
>>> <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi all,<br>
>>>><br>
>>>> I was playing with @SessionScoped beans... and wondered if<br>
>>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ?<br>
>>>><br>
>>>> At the moment these annotations belong to the javax.ejb package and are<br>
>>>> only used in @Stateful EJBs. With CDI scopes, we end up with a few<br>
>>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped,<br>
>>>> @ViewScoped...) so why not having the same functionality in CDI ?<br>
>>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not<br>
>>>> having @PostActivate and @PrePassivate as well so they could be used in<br>
>>>> every bean ?<br>
>>>><br>
>>>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to<br>
>>>> show me how to remove a bean from the session. It's only a few lines of<br>
>>>> code, but again, why not having a @Remove annotation that does that (the<br>
>>>> exact same one of javax.ejb.Remove) ?<br>
>>>><br>
>>>> To summarize, why not taking some of those stateful EJB concerns back to<br>
>>>> JSR 250 so they could be used anywhere ?<br>
>>>><br>
>>>> Any thoughts ?<br>
>>>><br>
>>>> --<br>
>>>> Antonio Goncalves<br>
>>>> Software architect, Java Champion and Pluralsight author<br>
>>>><br>
>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
>>>> _______________________________________________<br>
>>>> cdi-dev mailing list<br>
>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>>><br>
>>>> Note that for all code provided on this list, the provider licenses the<br>
>>>> code under the Apache License, Version 2<br>
>>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>>> provided on this list, the provider waives all patent and other intellectual<br>
>>>> property rights inherent in such information.<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> cdi-dev mailing list<br>
>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>><br>
>>> Note that for all code provided on this list, the provider licenses the<br>
>>> code under the Apache License, Version 2<br>
>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>> provided on this list, the provider waives all patent and other intellectual<br>
>>> property rights inherent in such information.<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Antonio Goncalves<br>
> Software architect, Java Champion and Pluralsight author<br>
><br>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code<br>
> under the Apache License, Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> provided on this list, the provider waives all patent and other intellectual<br>
> property rights inherent in such information.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div></div>
</div>