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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

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(a)gmail.com&gt; To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; Cc: weld-dev(a)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(a)yahoo.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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(a)gmail.com&gt; 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(a)yahoo.com&gt; 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(a)gmail.com&gt; >> To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; >> Cc: weld-dev(a)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(a)yahoo.com&gt; >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)yahoo.com&gt; 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(a)gmail.com&gt; To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; Cc: weld-dev(a)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(a)yahoo.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)yahoo.com&gt; > 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(a)gmail.com&gt; > To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; > Cc: weld-dev(a)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(a)yahoo.com&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > > > > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] TCK Interceptors Classes An: "Gurkan Erdogdu" <gurkanerdogdu(a)yahoo.com&gt; CC: weld-dev(a)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(a)yahoo.com&gt; 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(a)gmail.com&gt; > To: Marius Bogoevici <mariusb(a)redhat.com&gt; > Cc: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>; weld-dev(a)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(a)gmail.com&gt; 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(a)redhat.com&gt; >> 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)yahoo.com&gt; >>> 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(a)gmail.com&gt; >>> To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; >>> Cc: weld-dev(a)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(a)yahoo.com&gt; >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >>> >>> >>> >>> >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Gavin King 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. Yes, what we currently have in Weld and jboss-interceptors is based on the interpretation that @PostConstruct et al., when defined on an interceptor, are defining interceptor methods - and since the interceptor is initialized/destroyed at the same time with the target object - they serve to initialize/destroy the interceptor as well. Besides the arguments discussed before, I was also led towards my interpretation by the fact that the interceptors spec is driven by the EJB 3.1 spec, and this approach was consistent with what previously happened in EJB3. But you are right about the fact that in EE6 interceptors are managed beans as well, and in principle they could also have their own @PostConstruct/@PreDestroy events, separate from from the lifecycle events of the classes they intercept. There might be a wrinkle because of the Commons Annotations prohibition on having two distinct @PostConstruct methods - but this could just mean that an interceptor that specifies @PostConstruct void doStuff(){...} is initializing itself and may not specify a post-construct interception method for the target instance ). So - I'm also adding Ken to this discussion, hoping to get some clarifications on the actual intent of the interceptor specification for EJBs (and not only) - namely, whether the intent was to redefine @PostConstruct/@PreDestroy for interceptor classes (so that they are not initialization/cleanup methods for the interceptor instance itself, but interceptor methods for the target object ) or if this does really define a new set of callbacks.

> On Mon, Nov 30, 2009 at 3:08 PM, Marius Bogoevici > <mariusb(a)redhat.com&gt; 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(a)gmail.com&gt; >> 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(a)gmail.com&gt; >> 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(a)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(a)gmail.com&gt; >> To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; >> Cc: weld-dev(a)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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> >> >> >> >> > > > > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev