[cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ?
Romain Manni-Bucau
rmannibucau at gmail.com
Sun Dec 28 11:14:32 EST 2014
not really the points are:
1) do we want a big bundle in common annotations?
2) are these annotations used enough to be common?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-28 17:08 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
> 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 at yahoo.de> 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 at gmail.com>
>> 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 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>> >>>> France
>> _______________________________________________
>> >>>>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.
>> >>>
>> >
>> >_______________________________________________
>> >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.
>> >
>> >
More information about the cdi-dev
mailing list