[weld-dev] TCK Interceptors Classes
Kenneth Saks
Kenneth.Saks at Sun.COM
Tue Dec 1 09:46:59 EST 2009
On Dec 1, 2009, at 12:18 AM, Marius Bogoevici wrote:
> 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.
The original definition of @PostConstruct/@PreDestroy for interceptors
in EJB 3.0 was to interpose on the @PostConstruct/@PreDestroy of the
corresponding enterprise bean instance, not to define a separate
lifecycle callback for the interceptor instance itself. There was no
intent to change this in the Interceptors 1.1 spec other than to
describe it more generally as the relationship between an interceptor
instance and a target object. One of the defining characteristics
of an interceptor instance is that its lifecycle is identical to its
target object. It's confusing to define a @PostConstruct/@PreDestroy
with no InvocationContext because it implies there is a lifecycle
callback that is independent of the target object.
>
>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091201/f56eea91/attachment-0001.html
More information about the weld-dev
mailing list