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

Sun Dec 28 12:04:57 EST 2014

Yes, really good point : Extended Persistence Context....

Hum....

Antonio

On Sun, Dec 28, 2014 at 5:45 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> you surely forgot a detail only @Stateful handle: extended PC. That's
> where stateful makes sense and @Transactional doesn't help. Then there
> is nowhere else ATM where passivation is defined (even not in CDI with
> passivable things). Do you plan to specify it in CDI?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-28 17:42 GMT+01:00 Antonio Goncalves <antonio.goncalves at gmail.com
> >:
> > I should have explained my PoV a bit better. I'm trying to take the EJB
> > services, extract them, see if they could benefit for other components,
> if
> > yes, in which spec could they go.
> >
> > Today, there is less and less difference between :
> >
> > @Stateful
> > @SessionScoped
> > public class MySessionBean {
> >   @PersistenceContext
> >   EntityManager em;
> >   ...
> > }
> >
> > And :
> >
> > @Transactional
> > @SessionScoped
> > public class MySessionBean {
> >   @PersistenceContext
> >   EntityManager em;
> >   ...
> > }
> >
> > So I wonder if it would make sense to bother with @PostActivate,
> > @PrePassivate. I could see the benefit of @Remove though.
> >
> > Antonio
> >
> >
> > On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament <john.d.ament at gmail.com>
> >> wrote:
> >>>
> >>> 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.
> >>
> >>
> >> @PrePassivate/@PostActivate are used with @Stateful beans, which being
> >> unique instances are far less likely to be pooled. Pools are mostly
> used for
> >> @Stateless beans (if pools are used at all, the spec doesn't mandate
> those).
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >>>
> >>>
> >>> 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.
> >>
> >>
> >
> >
> >
> > --
> > 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.
>

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