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(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.

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(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. >

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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 &gt;&gt;&gt;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 &gt;&gt;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.

Seems like the clustering topic is going off course compared to Antonio's original question... On Sun Dec 28 2014 at 11:06:42 AM Mark Struberg <struberg(a)yahoo.de&gt; wrote: > > I agree with Romain. > > @John > > The problem is that there are many different kind of clusters. > And with many of them the serialize/deserialize are not 'symmetric' > > > Think about having e.g. having sticky sessions and a memcached which gets > each session pushed to after each request. And if there really is a node > outage then the load balancer will move the traffic from this node to > another one. On this new node the first thing is to try to load the session > from the memcached. And only if there is no such a session it will create a > fresh one (ofc rewrite the sessionId to allow subsequent fails). > > In this scenario you have multiple serializations, but the deserialize > only happens at maximum once (after an actual fail over). The > PrePassivate/PostActivate just doesn't work well with most of this > situations. > > > LieGrue, > strub > > > > On Sunday, 28 December 2014, 16:21, John D. Ament <john.d.ament(a)gmail.com&gt; > wrote: > > > > > > > >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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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 > &gt;&gt;&gt;&gt;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 > &gt;&gt;&gt;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 > &gt;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. > > > >

On 28 Dec 2014, at 12:38, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; 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(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.