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