6:55 a.m.
While researching the internals of Seam, I observed that interceptors
are not applied to methods that a component invokes on itself, even if
those are public. This would be any method that could be written
prefixed with "this." or "super.". This behavior differs from how
interceptors work on true proxies, of which session beans are an
example.
((MyComponent) Component.getInstance(MyComponent.class)).outerMethodCall();
// intercepted
@Name("myComponent")
public class MyComponent {
public void outerMethodCall() {
innerMethodCall(); // not intercepted
}
public void innerMethodCall() { }
}
Is this something we should try to fix or should we just document it
as expected behavior? Unfortunately, I find it quite limiting because
it takes away from the fine-grained control you would get when working
with things like transactions and security.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
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.
2:54 a.m.
I am pretty sure EJB has the same limitation.
On May 18, 2008, at 01:55, Dan Allen wrote:
While researching the internals of Seam, I observed that
interceptors
are not applied to methods that a component invokes on itself, even if
those are public. This would be any method that could be written
prefixed with "this." or "super.". This behavior differs from how
interceptors work on true proxies, of which session beans are an
example.
4:31 a.m.
On Sun, May 18, 2008 at 8:54 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
I am pretty sure EJB has the same limitation.
You are correct. Hmm. Fact of life I suppose.
This sounds to me like a great FAQ for the wiki. I will write it up as
soon as I get a chance. Just one of those good to know things.
I am guessing that Spring AOP would have the same limitation as well,
being based on JDK proxies. Out of curiosity, I wonder whether AspectJ
is able to catch such calls.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
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.
9:56 a.m.
Dan Allen schrieb:
On Sun, May 18, 2008 at 8:54 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> I am pretty sure EJB has the same limitation.
You are correct. Hmm. Fact of life I suppose.
This sounds to me like a great FAQ for the wiki. I will write it up as
soon as I get a chance. Just one of those good to know things.
I am guessing that Spring AOP would have the same limitation as well,
being based on JDK proxies. Out of curiosity, I wonder whether AspectJ
is able to catch such calls.
-Dan
JDK Proxies behave like a wrapper class (decorator). Once you are in the
wrapped class no internal method call will pass by the proxy.
If every call should be intercepted, Byte Code
instrumentation/generation is required. This can be provided for example
by cglib or javassist. The additional code for example interceptor code
will be written to the original class.
I don't know this part of the Seam source code but I am actually
wondering if Seam interceptors makes use of Javassist. I assume that
they use JDK proxies or if they use Javassist the code takes care that a
interceptor is only called once.
Best Regards
Sebastian
4:52 p.m.
On May 19, 2008, at 2:56 AM, Sebastian Hennebrueder wrote:
I don't know this part of the Seam source code but I am actually
wondering if Seam interceptors makes use of Javassist. I assume that
they use JDK proxies or if they use Javassist the code takes care
that a interceptor is only called once.
Seam uses javassist, but we use it to generate proxies not to
instrument the code. Since Seam doesn't control classloading, there's
no direct way we could do that. JBossAOP has really nice support for
this type of instrumentation, but of course this would only be a
viable option on JBoss where JBoss AOP is around and hooked into the
class loading process.
7:26 p.m.
Seam uses javassist, but we use it to generate proxies not to
instrument the
code.
Yep, exactly what I was about to write in response. So essentially we
are getting the same behavior as we would with a JDK proxy.
So the decision for the future is to whether this is just the way life
is going to be or whether we need to find a general approach to allow
more fine-grained interceptor calls. I doubt that JBoss AOP is the
only library that solves this problem. I have no doubt the Spring guys
will just love to kick us over this issue (given that AspectJ can
handle it). One response is that simplicity is better.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
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.
7:27 p.m.
As a side note, the comments in Components.java still read "use Cglib
to generate a proxy".
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
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.
7:45 p.m.
On May 19, 2008, at 12:26 PM, Dan Allen wrote:
So the decision for the future is to whether this is just the way
life
is going to be or whether we need to find a general approach to allow
more fine-grained interceptor calls. I doubt that JBoss AOP is the
only library that solves this problem. I have no doubt the Spring guys
will just love to kick us over this issue (given that AspectJ can
handle it). One response is that simplicity is better.
I really don't see it as that big of a deal. Seam needs to apply it's
processing when control passes into and out of the component. We
don't need, for example, to do injection on every internal method
call. (though I'll be honest here, I still don't see why we chose to
do this through injection rather than through contextually-ware
proxies) It's much more of a deal for EJB3-style tx/security
controls. (then again, we do those now, so...)
7:59 p.m.
How can AspectJ do this without having control over the classloader ?
AFAIK they have the exact same limitations.
/max
> Seam uses javassist, but we use it to generate proxies not to
instrument the
> code.
Yep, exactly what I was about to write in response. So essentially we
are getting the same behavior as we would with a JDK proxy.
So the decision for the future is to whether this is just the way life
is going to be or whether we need to find a general approach to allow
more fine-grained interceptor calls. I doubt that JBoss AOP is the
only library that solves this problem. I have no doubt the Spring guys
will just love to kick us over this issue (given that AspectJ can
handle it). One response is that simplicity is better.
-Dan
8:15 p.m.
Probably if you use aspectj and its extensions to the language, then
that needs to be compiled, possibly resulting in wanted behavior.
I guess you could use javassist to push interception code into your
components - probably what we're doing with jboss aop and pre-weaved code.
CC-ing Kabir to clear things up. :-)
Max Rydahl Andersen wrote:
How can AspectJ do this without having control over the classloader
?
AFAIK they have the exact same limitations.
/max
>> Seam uses javassist, but we use it to generate proxies not to instrument the
>> code.
> Yep, exactly what I was about to write in response. So essentially we
> are getting the same behavior as we would with a JDK proxy.
>
> So the decision for the future is to whether this is just the way life
> is going to be or whether we need to find a general approach to allow
> more fine-grained interceptor calls. I doubt that JBoss AOP is the
> only library that solves this problem. I have no doubt the Spring guys
> will just love to kick us over this issue (given that AspectJ can
> handle it). One response is that simplicity is better.
>
> -Dan
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
8:31 p.m.
From what Ales said, the problem is intercepting calls internally in
an EJB without calling via the container.
If you don't want to use a full AOP solution, then javassist can be
used to replace calls by using the javassist.expr.ExprEditor class
On 19 May 2008, at 19:15, Ales Justin wrote:
Probably if you use aspectj and its extensions to the language, then
that needs to be compiled, possibly resulting in wanted behavior.
I guess you could use javassist to push interception code into your
components - probably what we're doing with jboss aop and pre-weaved
code.
CC-ing Kabir to clear things up. :-)
Max Rydahl Andersen wrote:
> How can AspectJ do this without having control over the classloader ?
> AFAIK they have the exact same limitations.
> /max
>>> Seam uses javassist, but we use it to generate proxies not to
>>> instrument the
>>> code.
>> Yep, exactly what I was about to write in response. So essentially
>> we
>> are getting the same behavior as we would with a JDK proxy.
>>
>> So the decision for the future is to whether this is just the way
>> life
>> is going to be or whether we need to find a general approach to
>> allow
>> more fine-grained interceptor calls. I doubt that JBoss AOP is the
>> only library that solves this problem. I have no doubt the Spring
>> guys
>> will just love to kick us over this issue (given that AspectJ can
>> handle it). One response is that simplicity is better.
>>
>> -Dan
>>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
8:34 p.m.
On Mon, 19 May 2008 20:31:51 +0200, Kabir Khan <kabir.khan(a)jboss.com> wrote:
From what Ales said, the problem is intercepting calls internally
in
an EJB without calling via the container.
If you don't want to use a full AOP solution, then javassist can be
used to replace calls by using the javassist.expr.ExprEditor class
IFF you have control over the classloader...right ?
/max
On 19 May 2008, at 19:15, Ales Justin wrote:
> Probably if you use aspectj and its extensions to the language, then
> that needs to be compiled, possibly resulting in wanted behavior.
>
> I guess you could use javassist to push interception code into your
> components - probably what we're doing with jboss aop and pre-weaved
> code.
>
> CC-ing Kabir to clear things up. :-)
>
> Max Rydahl Andersen wrote:
>> How can AspectJ do this without having control over the classloader ?
>> AFAIK they have the exact same limitations.
>> /max
>>>> Seam uses javassist, but we use it to generate proxies not to
>>>> instrument the
>>>> code.
>>> Yep, exactly what I was about to write in response. So essentially
>>> we
>>> are getting the same behavior as we would with a JDK proxy.
>>>
>>> So the decision for the future is to whether this is just the way
>>> life
>>> is going to be or whether we need to find a general approach to
>>> allow
>>> more fine-grained interceptor calls. I doubt that JBoss AOP is the
>>> only library that solves this problem. I have no doubt the Spring
>>> guys
>>> will just love to kick us over this issue (given that AspectJ can
>>> handle it). One response is that simplicity is better.
>>>
>>> -Dan
>>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
8:40 p.m.
Yeah, you either need to do it when the bean class is first loaded
(using the -javaagent switch), or as a post compilation step. What are
you referring to wrt AspectJ?
On 19 May 2008, at 19:34, Max Rydahl Andersen wrote:
On Mon, 19 May 2008 20:31:51 +0200, Kabir Khan
<kabir.khan(a)jboss.com> wrote:
> From what Ales said, the problem is intercepting calls internally in
> an EJB without calling via the container.
> If you don't want to use a full AOP solution, then javassist can be
> used to replace calls by using the javassist.expr.ExprEditor class
IFF you have control over the classloader...right ?
/max
> On 19 May 2008, at 19:15, Ales Justin wrote:
>
>> Probably if you use aspectj and its extensions to the language, then
>> that needs to be compiled, possibly resulting in wanted behavior.
>>
>> I guess you could use javassist to push interception code into your
>> components - probably what we're doing with jboss aop and pre-weaved
>> code.
>>
>> CC-ing Kabir to clear things up. :-)
>>
>> Max Rydahl Andersen wrote:
>>> How can AspectJ do this without having control over the
>>> classloader ?
>>> AFAIK they have the exact same limitations.
>>> /max
>>>>> Seam uses javassist, but we use it to generate proxies not to
>>>>> instrument the
>>>>> code.
>>>> Yep, exactly what I was about to write in response. So essentially
>>>> we
>>>> are getting the same behavior as we would with a JDK proxy.
>>>>
>>>> So the decision for the future is to whether this is just the way
>>>> life
>>>> is going to be or whether we need to find a general approach to
>>>> allow
>>>> more fine-grained interceptor calls. I doubt that JBoss AOP is the
>>>> only library that solves this problem. I have no doubt the Spring
>>>> guys
>>>> will just love to kick us over this issue (given that AspectJ can
>>>> handle it). One response is that simplicity is better.
>>>>
>>>> -Dan
>>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
8:38 a.m.
On Mon, 19 May 2008 20:40:40 +0200, Kabir Khan <kabir.khan(a)jboss.com> wrote:
Yeah, you either need to do it when the bean class is first loaded
(using the -javaagent switch), or as a post compilation step. What are
you referring to wrt AspectJ?
I was just opposing that AspectJ should have some mystical voodoo power compared to
javassist.
AFAIK the only way for AspectJ or javaassist to provide innerMethod calls to be proxied
is by controlling the classloader OR disallowing the new operator to be used and only
hand out instances via factories.
-max
On 19 May 2008, at 19:34, Max Rydahl Andersen wrote:
> On Mon, 19 May 2008 20:31:51 +0200, Kabir Khan
> <kabir.khan(a)jboss.com> wrote:
>
>> From what Ales said, the problem is intercepting calls internally in
>> an EJB without calling via the container.
>> If you don't want to use a full AOP solution, then javassist can be
>> used to replace calls by using the javassist.expr.ExprEditor class
>
>
> IFF you have control over the classloader...right ?
>
> /max
>
>> On 19 May 2008, at 19:15, Ales Justin wrote:
>>
>>> Probably if you use aspectj and its extensions to the language, then
>>> that needs to be compiled, possibly resulting in wanted behavior.
>>>
>>> I guess you could use javassist to push interception code into your
>>> components - probably what we're doing with jboss aop and pre-weaved
>>> code.
>>>
>>> CC-ing Kabir to clear things up. :-)
>>>
>>> Max Rydahl Andersen wrote:
>>>> How can AspectJ do this without having control over the
>>>> classloader ?
>>>> AFAIK they have the exact same limitations.
>>>> /max
>>>>>> Seam uses javassist, but we use it to generate proxies not to
>>>>>> instrument the
>>>>>> code.
>>>>> Yep, exactly what I was about to write in response. So essentially
>>>>> we
>>>>> are getting the same behavior as we would with a JDK proxy.
>>>>>
>>>>> So the decision for the future is to whether this is just the way
>>>>> life
>>>>> is going to be or whether we need to find a general approach to
>>>>> allow
>>>>> more fine-grained interceptor calls. I doubt that JBoss AOP is the
>>>>> only library that solves this problem. I have no doubt the Spring
>>>>> guys
>>>>> will just love to kick us over this issue (given that AspectJ can
>>>>> handle it). One response is that simplicity is better.
>>>>>
>>>>> -Dan
>>>>>
>>>> _______________________________________________
>>>> seam-dev mailing list
>>>> seam-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
>
>
11:04 a.m.
That is my understanding as well
On 20 May 2008, at 07:38, Max Rydahl Andersen wrote:
On Mon, 19 May 2008 20:40:40 +0200, Kabir Khan
<kabir.khan(a)jboss.com> wrote:
> Yeah, you either need to do it when the bean class is first loaded
> (using the -javaagent switch), or as a post compilation step. What
> are
> you referring to wrt AspectJ?
I was just opposing that AspectJ should have some mystical voodoo
power compared to
javassist.
AFAIK the only way for AspectJ or javaassist to provide innerMethod
calls to be proxied
is by controlling the classloader OR disallowing the new operator to
be used and only
hand out instances via factories.
-max
> On 19 May 2008, at 19:34, Max Rydahl Andersen wrote:
>
>> On Mon, 19 May 2008 20:31:51 +0200, Kabir Khan
>> <kabir.khan(a)jboss.com> wrote:
>>
>>> From what Ales said, the problem is intercepting calls internally
>>> in
>>> an EJB without calling via the container.
>>> If you don't want to use a full AOP solution, then javassist can be
>>> used to replace calls by using the javassist.expr.ExprEditor class
>>
>>
>> IFF you have control over the classloader...right ?
>>
>> /max
>>
>>> On 19 May 2008, at 19:15, Ales Justin wrote:
>>>
>>>> Probably if you use aspectj and its extensions to the language,
>>>> then
>>>> that needs to be compiled, possibly resulting in wanted behavior.
>>>>
>>>> I guess you could use javassist to push interception code into
>>>> your
>>>> components - probably what we're doing with jboss aop and pre-
>>>> weaved
>>>> code.
>>>>
>>>> CC-ing Kabir to clear things up. :-)
>>>>
>>>> Max Rydahl Andersen wrote:
>>>>> How can AspectJ do this without having control over the
>>>>> classloader ?
>>>>> AFAIK they have the exact same limitations.
>>>>> /max
>>>>>>> Seam uses javassist, but we use it to generate proxies not
to
>>>>>>> instrument the
>>>>>>> code.
>>>>>> Yep, exactly what I was about to write in response. So
>>>>>> essentially
>>>>>> we
>>>>>> are getting the same behavior as we would with a JDK proxy.
>>>>>>
>>>>>> So the decision for the future is to whether this is just the
>>>>>> way
>>>>>> life
>>>>>> is going to be or whether we need to find a general approach to
>>>>>> allow
>>>>>> more fine-grained interceptor calls. I doubt that JBoss AOP is
>>>>>> the
>>>>>> only library that solves this problem. I have no doubt the
>>>>>> Spring
>>>>>> guys
>>>>>> will just love to kick us over this issue (given that AspectJ
>>>>>> can
>>>>>> handle it). One response is that simplicity is better.
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>> _______________________________________________
>>>>> seam-dev mailing list
>>>>> seam-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>
>>
>>
>
>
5827
days inactive
5829
days old
14 comments
7 participants
participants (7)
-
Ales Justin -
Dan Allen -
Emmanuel Bernard -
Kabir Khan -
Max Rydahl Andersen -
Norman Richards -
Sebastian Hennebrueder