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,
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(a)gmail.com>
Issue with XActivate is nothing is specified on what does mean
(think to a cluster)
Le 28 déc. 2014 13:52, "John D. Ament" <john.d.ament(a)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.
> 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 <http://www.antoniogoncalves.org>
>> JUG <http://www.parisjug.org>
| Devoxx France <http://www.devoxx.fr>
>> cdi-dev mailing list
>> 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
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.