[weld-dev] TCK Interceptors Classes

Mark Struberg struberg at yahoo.de
Tue Dec 1 02:47:26 EST 2009 

To sum this up the current interpretation:

An interceptor may have exactly one of 

@PostDestroy void doDestroy();
or
@PostDestroy void doDestroy(InvocationContext ivc);

(same for @PostConstruct)

The 1st case only manages the cleanup on the interceptor itself, whereas the 2nd form in addition allows to cleanup the intercepted bean too. Correct so far?

Thinking about that, I'm not sure if we need the 2nd form at all: The interceptor has the exact same lifecycle as the intercepted bean, isn't? are there any exceptions? So imho the 2nd form only would be called if the intercepted bean defines a @PreDestroy on it's own. But because this must be executed even if the interceptor doesn't define a @PreDestroy at all, i don't think it's of any use. 

If you e.g. need an opened transaction in the beans cleanup() you simply would write
@PreDestroy @Transactional void cleanup();

So I cannot think of any real usecase where we'd need the 2nd form.

Otoh a pure @PreDestroy (without the InvocationContext) on the interceptor makes a lot of sense for freeing resouces etc.

LieGrue,
strub

--- Gavin King <gavin.king at gmail.com> schrieb am Di, 1.12.2009:

> Von: Gavin King <gavin.king at gmail.com>
> Betreff: Re: [weld-dev] TCK Interceptors Classes
> An: "Gurkan Erdogdu" <gurkanerdogdu at yahoo.com>
> CC: weld-dev at lists.jboss.org
> Datum: Dienstag, 1. Dezember 2009, 6:50
> I don't see why it's absurd. Not even
> remotely. There can certainly be
> two events here, one event being the destruction of the
> intercepted
> bean, the other event being the destruction of the
> interceptor.
> 
> We certainly do need to establish what the specs are
> intending to say, however.
> 
> It seems that the EE, interceptor and managed bean specs
> are more or
> less ambiguous here. However, common annotations strongly
> favors the
> interpretation that the "lifecycle callback interceptor
> method"
> mentioned by the interceptors spec is exactly the same
> thing as the
> "@PostConstruct" or "@PreDestroy" method that the other
> specs talk
> about. Furthermore, if there can be two methods, the specs
> don't
> define what order they occur in. So I think that Marius has
> the
> correct interpretation, even if it not the interpretation
> that was
> most intuitive to me.
> 
> On Tue, Dec 1, 2009 at 12:24 AM, Gurkan Erdogdu <gurkanerdogdu at yahoo.com>
> wrote:
> > I think that it is absurd to have two different
> @PreDestroy methods in
> > interceptor class.Because they have same
> functionality. InvocationContext
> > solely exists in the interceptor specification and it
> is very logical.
> > Because one wants to call next interceptor in the
> chain.
> >
> > Will TCK tests be corrected?
> >
> > Thanks;
> >
> > --Gurkan
> >
> > ________________________________
> > From: Gavin King <gavin.king at gmail.com>
> > To: Marius Bogoevici <mariusb at redhat.com>
> > Cc: Gurkan Erdogdu <gurkanerdogdu at yahoo.com>;
> weld-dev at lists.jboss.org
> > Sent: Mon, November 30, 2009 10:43:42 PM
> > Subject: Re: [weld-dev] TCK Interceptors Classes
> >
> > Well, the problem is that the interceptors spec is in
> general not very
> > clearly written.
> >
> > On Mon, Nov 30, 2009 at 3:42 PM, Gavin King <gavin.king at gmail.com>
> wrote:
> >> Hrm section 2.6 of the common annotations spec
> seems to confirm your
> >> interpretation. What's very problematic here is
> that the interceptors
> >> spec uses a different terminology to talk about
> the callbacks that it
> >> is defining. Which leads to my interpretation that
> it is defining a
> >> different, distinct set of callbacks.
> >>
> >> On Mon, Nov 30, 2009 at 3:08 PM, Marius Bogoevici
> <mariusb at redhat.com>
> >> wrote:
> >>> Gavin,
> >>>
> >>> This is very ambiguous, as the 1.1 version of
> the Interceptors
> >>> specification
> >>> states very clearly the signature rules for
> defining lifecycle
> >>> interceptor
> >>> methods on interceptor classes and target
> classes.
> >>>
> >>> Also, this could mean that an interceptor
> class can specify two different
> >>> @PostConstruct or @PreDestroy methods, which
> would refer to different
> >>> targets (the intercepted instance/the
> interceptor itself), but the
> >>> specification says very clearly:
> >>> "At most one method of a given interceptor
> class can be designated as an
> >>> around-invoke method, an around-timeout
> method, a post-construct method,
> >>> or
> >>> pre-destroy method."
> >>>
> >>> Also, it is not very clear to me what would be
> the benefit of a separate
> >>> @PostConstruct/@PreDestroy method for the
> interceptor itself, as
> >>> interceptor
> >>> lifecycles are virtually the same as for the
> target objects.
> >>>
> >>> Marius
> >>>
> >>>
> >>>
> >>> Gavin King wrote:
> >>>
> >>> Check section 5.2.5 of the EE spec. It appears
> to confirm my
> >>> understanding of this stuff.
> >>>
> >>> On Mon, Nov 30, 2009 at 2:33 PM, Gavin King
> <gavin.king at gmail.com>
> wrote:
> >>>
> >>>
> >>> At least, that's my understanding of how
> interceptors are treated in
> >>> EE6. You would have to check with Roberto and
> Ken for an absolutely
> >>> definitive answer.
> >>>
> >>> On Mon, Nov 30, 2009 at 2:32 PM, Gavin King
> <gavin.king at gmail.com>
> wrote:
> >>>
> >>>
> >>> Right, but the interceptor itself has a
> lifecycle. It's a kind of
> >>> managed bean. So it can have the callbacks
> that all managed beans can
> >>> have.
> >>>
> >>> On Mon, Nov 30, 2009 at 2:17 PM, Gurkan
> Erdogdu <gurkanerdogdu at yahoo.com>
> >>> wrote:
> >>>
> >>>
> >>> There are two differents scenario for
> lifecycle callbacks in interceptors
> >>> specification
> >>>
> >>> 1* Used in interceptor class with
> InvocationContext parameter
> >>>      @PreDestroy
> >>>      public void
> blabla(InvocationContext){}
> >>> 2* Used in bean class without any parameter
> >>>      @PreDestroy
> >>>      public void blabla(){}
> >>>
> >>> In TCK, @PreDestroy is used in interceptor
> class. So it may take
> >>> InvocationContext.
> >>>
> >>> --Gurkan
> >>>
> >>> ________________________________
> >>> From: Gavin King <gavin.king at gmail.com>
> >>> To: Gurkan Erdogdu <gurkanerdogdu at yahoo.com>
> >>> Cc: weld-dev at lists.jboss.org
> >>> Sent: Mon, November 30, 2009 9:10:17 PM
> >>> Subject: Re: [weld-dev] TCK Interceptors
> Classes
> >>>
> >>> Hrm, I think there are two kinds of
> @PreDestroy methods for an
> >>> interceptor:
> >>>
> >>> @PreDestroy void foo(InvocationContext) { ..
> }  -> the intercepted
> >>> bean is being destroyed
> >>> @PreDestroy void foo() { .. }  -> the
> interceptor itself is being
> >>> destroyed
> >>>
> >>> Right?
> >>>
> >>> On Mon, Nov 30, 2009 at 1:34 PM, Gurkan
> Erdogdu <gurkanerdogdu at yahoo.com>
> >>> wrote:
> >>>
> >>>
> >>> Hi;
> >>>
> >>> Some interceptors classes in the TCK test
> suites implement @PreDestroy
> >>> methods. AFAIK, interceptors specification
> says that methods with
> >>> @PreDestroy in interceptor class must take
> InvocationContext parameter.
> >>> But
> >>> in TCK, those methods do not take
> InvocationContext parameter
> >>>
> >>> For example:
> >>>
> >>>
> org.jboss.jsr299.tck.tests.context.dependent.TransactionalInterceptor
> >>>
> >>> @PreDestroy public void destroy()
> >>>    {
> >>>       destroyed = true;
> >>>    }
> >>>
> >>> Is it correct?
> >>>
> >>> --Gurkan
> >>>
> >>>
> >>>
> >>>
> >>>
> _______________________________________________
> >>> weld-dev mailing list
> >>> weld-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Gavin King
> >>> gavin.king at gmail.com
> >>> http://in.relation.to/Bloggers/Gavin
> >>> http://hibernate.org
> >>> http://seamframework.org
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Gavin King
> >>> gavin.king at gmail.com
> >>> http://in.relation.to/Bloggers/Gavin
> >>> http://hibernate.org
> >>> http://seamframework.org
> >>>
> >>>
> >>>
> >>> --
> >>> Gavin King
> >>> gavin.king at gmail.com
> >>> http://in.relation.to/Bloggers/Gavin
> >>> http://hibernate.org
> >>> http://seamframework.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Gavin King
> >> gavin.king at gmail.com
> >> http://in.relation.to/Bloggers/Gavin
> >> http://hibernate.org
> >> http://seamframework.org
> >>
> >
> >
> >
> > --
> > Gavin King
> > gavin.king at gmail.com
> > http://in.relation.to/Bloggers/Gavin
> > http://hibernate.org
> > http://seamframework.org
> >
> >
> 
> 
> 
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com

More information about the weld-dev mailing list