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
2014-12-28 17:08 GMT+01:00 John D. Ament <john.d.ament(a)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(a)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(a)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(a)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(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.
> >>>
> >>>
> >>>John
> >>>
> >>>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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >>>> France
> _______________________________________________
> >>>>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.
> >>>
> >
> >_______________________________________________
> >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.
> >
> >