12:34 p.m.
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
1:10 p.m.
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:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:17 p.m.
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>
To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>
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:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:32 p.m.
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:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:33 p.m.
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:38 p.m.
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:08 p.m.
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:
2:42 p.m.
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:43 p.m.
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:24 p.m.
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>
To: Marius Bogoevici <mariusb(a)redhat.com>
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:50 p.m.
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> wrote:
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:47 a.m.
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(a)gmail.com> schrieb am Di, 1.12.2009:
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
11:18 p.m.
Gavin King wrote:
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.
8:46 a.m.
On Dec 1, 2009, at 12:18 AM, Marius Bogoevici wrote:
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.
5595
days inactive
5596
days old
13 comments
5 participants
participants (5)
-
Gavin King -
Gurkan Erdogdu -
Kenneth Saks -
Marius Bogoevici -
Mark Struberg