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

[John D. Ament]

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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/dcd23f12/attachment-0001.html