[webbeans-dev] RE: Removal of pluggability contracts

[Jim Knutson]

Trying to get up to speed and provide feedback... <greetings all>

I'm not following the exact conversation here, so let me see if I can play
it back.  SFSBs have a lifecycle defined by the EJB spec.  The WebBeans
spec. makes reference to WebBeans remove methods (unique to WebBeans) that
governed the lifecycle in a different way than the EJB @Remove method.  The
WebBeans spec. is now going to remove the WebBeans specific remove method.
So far so good I think.

However, there were references to @Remove being for clients, not the
container.  That I'm having trouble with.  Since the context is acting as a
client to both create and destroy instances at appropriate times, shouldn't
it drive the appropriate lifecycle methods?  Also, there's a potential flaw
in the EJB spec. that would prevent PreDestroy notification.  The SFSB
section states: "PreDestroy methods execute after any method annotated with
the Remove annotation has completed.".  Literally, a container could
potentially not invoke PreDestroy if the @Remove method is not called at
all.

Is there some rationale for why the context lifecycle management shouldn't
drive the typical client lifecycle methods of the beans?

Thanks,
Jim Knutson
WebSphere J2EE Architect


                                                                           
             Michael Keith                                                 
             <MICHAEL.KEITH at or                                             
             acle.com>                                                  To 
                                       Gavin King <gavin at hibernate.org>,   
             12/22/2008 11:43          Java Community Process JSR #299     
             AM                        Expert List <JSR-299-EG at jcp.org>,   
                                       Jim Knutson/Austin/IBM at IBMUS,       
                                       WebBeans                            
                                       <webbeans-dev at lists.jboss.org>      
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: Removal of pluggability         
                                       contracts                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Gavin,

Given that one of the primary characteristics of a context is its duration,

which may not line up exactly with the life cycle of the component itself,
one has to accept that there are going to need to be some extensions to the
life cycle of the component.

However, an extension to an existing life cycle is quite different from
defining an additional life cycle, which implies an additional component.
This is a somewhat separate discussion, though, that I won't get into now.
but that I think needs to be on the table at some point.

Anytime the life cycle of the context can make use of the existing life
cycle
of the component then it is definitely an improvement, so this proposed
change
is a good one, IMO.

> -----Original Message-----
> From: Gavin King [mailto:gavin at hibernate.org]
> Sent: Saturday, December 20, 2008 11:17 PM
> To: Java Community Process JSR #299 Expert List; Michael Keith; Jim
> Knutson; WebBeans
> Subject: Re: Removal of pluggability contracts
>
>
> On Sun, Dec 21, 2008 at 3:03 PM, Gavin King
> <gavin at hibernate.org> wrote:
>
> > SFSBs with no web bean remove method
> > ================================
> > We have an open issue w.r.t destruction of SFSBs which have no web
> > bean remove method. Now that the requirement for
> pluggability is gone,
> > I think we should simply say that in this case, the container must
> > destroy the SFSB when its context ends *without* calling any remove
> > method.
> >
> > I will go ahead and make that change unless there is someone who
> > objects to this.
>
> Alternatively, we could actually go further than this and simply
> eliminate the concept of the "Web Bean remove method" and the
> @Destructor annotation. @Remove methods are really intended to be
> called by clients, not by the container - and if you just want a
> callback, we already have @PreDestroy. I'm not sure that @Destructor
> is really adding any additional value.
>
> The more I think about this, the more I think this is the right way to
> go (and it simplifies the spec).
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090106/211a0cbf/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20090106/211a0cbf/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic02029.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20090106/211a0cbf/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20090106/211a0cbf/attachment-0002.gif