<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin King wrote:
<blockquote
cite="mid:db199550911301242y9486ec4q462774c410da61d@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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. <br>
<br>
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. <br>
<br>
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 ).<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:db199550911301242y9486ec4q462774c410da61d@mail.gmail.com"
type="cite">
<pre wrap="">
On Mon, Nov 30, 2009 at 3:08 PM, Marius Bogoevici <a class="moz-txt-link-rfc2396E" href="mailto:mariusb@redhat.com"><mariusb@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:gavin.king@gmail.com"><gavin.king@gmail.com></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:gavin.king@gmail.com"><gavin.king@gmail.com></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:gurkanerdogdu@yahoo.com"><gurkanerdogdu@yahoo.com></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:gavin.king@gmail.com"><gavin.king@gmail.com></a>
To: Gurkan Erdogdu <a class="moz-txt-link-rfc2396E" href="mailto:gurkanerdogdu@yahoo.com"><gurkanerdogdu@yahoo.com></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:gurkanerdogdu@yahoo.com"><gurkanerdogdu@yahoo.com></a>
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
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a>
--
Gavin King
<a class="moz-txt-link-abbreviated" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a>
<a class="moz-txt-link-freetext" href="http://hibernate.org">http://hibernate.org</a>
<a class="moz-txt-link-freetext" href="http://seamframework.org">http://seamframework.org</a>
--
Gavin King
<a class="moz-txt-link-abbreviated" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a>
<a class="moz-txt-link-freetext" href="http://hibernate.org">http://hibernate.org</a>
<a class="moz-txt-link-freetext" href="http://seamframework.org">http://seamframework.org</a>
--
Gavin King
<a class="moz-txt-link-abbreviated" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a>
<a class="moz-txt-link-freetext" href="http://hibernate.org">http://hibernate.org</a>
<a class="moz-txt-link-freetext" href="http://seamframework.org">http://seamframework.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>