10:55 p.m.
I'm looking at a support issue, and I've found a problem with
MethodContextInterceptor. The interceptor puts the calling component,
by name, in the method context so that future calls to getInstance()
will find that version of the component. However, it sets the raw,
unproxied object so that calls to that object will not go through the
interceptor chain. (so, an annotation like @CreateProcess won't be
triggered). This seems wrong to me, but since I don't understand the
purpose of MethodContextInterceptor, I can't say for sure.
In case the description above isn't clear, consider a simple component
like this:
...
@Name("foo")
public class Foo {
@RaiseEvent("myEvent")
public void actionOne() { }
@CreateProcess(...)
@Observe("myEvent")
public void actionTwo() { }
}
When #{foo.one} is invoked, the unproxied Foo instance is put in the
method context under "foo". When the event is raised, Events tries to
lookup "foo" but instead of finding the correct instance in it's
normal context, it finds the raw instance in the method context.
actionTwo() is called, but there are no proxies involved and thus
@CreateProcess isn't triggered.
So, what in the world is the MethodContextInterceptor doing there?
Should it really be storing the unproxied instance there?
11:39 p.m.
Ah! Now things make sense. In the thread discussing how interceptors
are not applied on self methods, I didn't understand why they weren't
being applied even when I called getInstance() before calling the
method (or as Norman points out, raising a synchronous event). Now I
understand. If I specify the scope explicitly, then it gets the
proxied instance and the interceptors are applied:
// interceptors not applied (MethodContextInterceptor in the way)
((MyComponent) Component.getInstance("myComponent")).callMe()
// interceptors applied
((MyComponent) Component.getInstance("myComponent", ScopeType.EVENT)).callMe();
For a while, I thought I was going insane. In reality, I was being
bitten by the MethodContextInterceptor.
I don't think there is no reason to put the unproxied instead in the
method context. The Seam interceptors, the BijectionInterceptor in
particular, already deal with reentrant calls. So its not like this is
preventing things from breaking. If anything, it is just screwing with
the minds of poor developers wondering why interceptors are not
applied.
-Dan
On Mon, Jun 9, 2008 at 4:55 PM, Norman Richards <orb(a)nostacktrace.com> wrote:
I'm looking at a support issue, and I've found a problem
with
MethodContextInterceptor. The interceptor puts the calling component, by
name, in the method context so that future calls to getInstance() will find
that version of the component. However, it sets the raw, unproxied object
so that calls to that object will not go through the interceptor chain.
(so, an annotation like @CreateProcess won't be triggered). This seems
wrong to me, but since I don't understand the purpose of
MethodContextInterceptor, I can't say for sure.
In case the description above isn't clear, consider a simple component like
this:
...
@Name("foo")
public class Foo {
@RaiseEvent("myEvent")
public void actionOne() { }
@CreateProcess(...)
@Observe("myEvent")
public void actionTwo() { }
}
When #{foo.one} is invoked, the unproxied Foo instance is put in the method
context under "foo". When the event is raised, Events tries to lookup
"foo"
but instead of finding the correct instance in it's normal context, it finds
the raw instance in the method context. actionTwo() is called, but there
are no proxies involved and thus @CreateProcess isn't triggered.
So, what in the world is the MethodContextInterceptor doing there? Should
it really be storing the unproxied instance there?
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
11:40 p.m.
I don't think there is no reason to put the unproxied instead in
the
method context.
This should read: I don't think there is any reason to put the
unproxied instance in the method context.
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
11:40 p.m.
This is correct, it prevents some very wrong behavior when the
component is invoked recursively.
On 6/9/08, Norman Richards <orb(a)nostacktrace.com> wrote:
I'm looking at a support issue, and I've found a problem
with
MethodContextInterceptor. The interceptor puts the calling component, by
name, in the method context so that future calls to getInstance() will find
that version of the component. However, it sets the raw, unproxied object
so that calls to that object will not go through the interceptor chain.
(so, an annotation like @CreateProcess won't be triggered). This seems
wrong to me, but since I don't understand the purpose of
MethodContextInterceptor, I can't say for sure.
In case the description above isn't clear, consider a simple component like
this:
...
@Name("foo")
public class Foo {
@RaiseEvent("myEvent")
public void actionOne() { }
@CreateProcess(...)
@Observe("myEvent")
public void actionTwo() { }
}
When #{foo.one} is invoked, the unproxied Foo instance is put in the method
context under "foo". When the event is raised, Events tries to lookup
"foo"
but instead of finding the correct instance in it's normal context, it finds
the raw instance in the method context. actionTwo() is called, but there
are no proxies involved and thus @CreateProcess isn't triggered.
So, what in the world is the MethodContextInterceptor doing there? Should
it really be storing the unproxied instance there?
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:47 p.m.
On Mon, Jun 9, 2008 at 5:40 PM, Gavin King <gavin(a)hibernate.org> wrote:
This is correct, it prevents some very wrong behavior when the
component is invoked recursively.
Hmmm, so its one of those "damned if you do, damned if you don't".
There is one possible workaround. The Events component could skip the
METHOD context when looking up the observers. The other solution is to
use the example I gave and lookup the component outside of the METHOD
scope.
Regardless of what we decide, it would probably be a good idea to let
users know (in the docs) that the unproxied instance is sitting in the
METHOD context.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
12:32 a.m.
On Jun 9, 2008, at 4:47 PM, Dan Allen wrote:
On Mon, Jun 9, 2008 at 5:40 PM, Gavin King
<gavin(a)hibernate.org>
wrote:
> This is correct, it prevents some very wrong behavior when the
> component is invoked recursively.
Hmmm, so its one of those "damned if you do, damned if you don't".
There is one possible workaround. The Events component could skip the
METHOD context when looking up the observers. The other solution is to
use the example I gave and lookup the component outside of the METHOD
scope.
The Events context can push a new method context before raising an
event and pop it back afterwards to solve the problem, though I
suspect that would nullify that SFSB unwrapping protection that it
appears the method context interceptor was trying to solve. I'll have
to test it out.
9:17 p.m.
Is there a JIRA created for this? Any word I can give to the customer,
from the discussion so far the solutions/workarounds are mainly in the
Seam code not customer facing.
Regards,
Samuel
Norman Richards wrote:
On Jun 9, 2008, at 4:47 PM, Dan Allen wrote:
> On Mon, Jun 9, 2008 at 5:40 PM, Gavin King <gavin(a)hibernate.org> wrote:
>> This is correct, it prevents some very wrong behavior when the
>> component is invoked recursively.
>
> Hmmm, so its one of those "damned if you do, damned if you don't".
> There is one possible workaround. The Events component could skip the
> METHOD context when looking up the observers. The other solution is to
> use the example I gave and lookup the component outside of the METHOD
> scope.
The Events context can push a new method context before raising an
event and pop it back afterwards to solve the problem, though I
suspect that would nullify that SFSB unwrapping protection that it
appears the method context interceptor was trying to solve. I'll have
to test it out.
9:21 p.m.
On Jun 11, 2008, at 2:17 PM, Samuel Mendenhall wrote:
Is there a JIRA created for this? Any word I can give to the
customer, from the discussion so far the solutions/workarounds are
mainly in the Seam code not customer facing.
http://jira.jboss.com/jira/browse/JBSEAM-3094
9:26 p.m.
On Jun 11, 2008, at 2:21 PM, Norman Richards wrote:
On Jun 11, 2008, at 2:17 PM, Samuel Mendenhall wrote:
> Is there a JIRA created for this? Any word I can give to the
> customer, from the discussion so far the solutions/workarounds are
> mainly in the Seam code not customer facing.
http://jira.jboss.com/jira/browse/JBSEAM-3094
er....
http://jira.jboss.com/jira/browse/JBSEAM-3095
5797
days inactive
5799
days old
8 comments
4 participants
participants (4)
-
Dan Allen -
Gavin King -
Norman Richards -
Samuel Mendenhall