[cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ?

[John D. Ament]

What would cluster have to do with it?  I believe standard practice (since
EE doesn't define "cluster") is that when an EJB is used in a cluster, it's
expected that SFSB's get replicated to other nodes w/ state in tact.  So
the bean wouldn't be "re-activated" per se.

On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> Issue with XActivate is nothing is specified on what does mean activate
> (think to a cluster)
> Le 28 déc. 2014 13:52, "John D. Ament" <john.d.ament at gmail.com> a écrit :
>
> PostActivate/PrePassivate are only applicable to EJBs (as of now).  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.
>>
>> 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 at 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 <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>  _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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 at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/3fc2f074/attachment.html