JDK Style Proxy Issue

[Mark Menard]

I am in the process of chasing down an issue that started when I tried to
use 1.1-beta-2 with Spring's Groovy script support. (Not compiled scripts.)

The issue seems to be that if a groovy object calls a method on another
groovy object that is wrapped in a proxy it throws a
"java.lang.IllegalArgumentException: object is not an instance of declaring
class."

My questions to you the developers of Groovy:

1. Is this an intended behavior? Are JDK style proxies not supported in
Groovy? (They did work in Groovy 1.0.)

2. If this should work where should I start poking at the code to see what
might be causing this?

I'm willing to help, but I'd like to know if I'm barking up the wrong tree
and wasting my time (ala anonymous inner classes, never did like them). Do
you think this is a MOP issue? Is it fundamentally incompatible with the
direction of Groovy?

My use case for this is using Spring's scripting support with Groovy Beans
with Spring's AOP style transaction support, which is implemented using
proxies. I have built a rather large application using this framework over
the past year, and it works great in Groovy 1.0. I'd just like to know if
I'm facing a dead end with Groovy, and if I need to find either a non-proxy
based solution, or that I'm stuck with Groovy 1.0. (Being stuck with Groovy
1.0 really isn't a solution. I'd either have to port back to Java, or find
some other solution. I'd really rather not need to redo a years worth of
work though.)

I have posted on this issue in the user list:

http://www.nabble.com/1.1-beta-2-Dynamic-Proxy-Issue-tf4132988.html

Again any insight, ideas, conjectures, guesses... basically anything would
be appreciated. I'll work on it. I can bang rocks together.

Thanks,

Mark
--
Mark Menard
personal: http://www.vitarara.org/
business: http://www.vitarara.net/


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

I don't know if this is helpful but with compiled classes in my project, I'm pretty sure I'm not seeing this behavior with Spring. I'm using Spring AOP for logging and catching exceptions. I have compiled Groovy classes not managed by Spring that invoke methods on other compiled Groovy classes that are managed by Spring and I'm not seeing IllegalArgumentException. I am running into another problem trying to do some method logging but I don't think the problem in with Groovy and Spring; however I don't know *for sure* yet what the problem is.
 
Scott

----- Original Message ----
From: Mark Menard <mark@...>
To: dev@...
Sent: Tuesday, July 24, 2007 1:22:14 PM
Subject: [groovy-dev] JDK Style Proxy Issue

I am in the process of chasing down an issue that started when I tried to
use 1.1-beta-2 with Spring's Groovy script support. (Not compiled scripts.)

The issue seems to be that if a groovy object calls a method on another
groovy object that is wrapped in a proxy it throws a
"java.lang.IllegalArgumentException: object is not an instance of declaring
class."

My questions to you the developers of Groovy:

1. Is this an intended behavior? Are JDK style proxies not supported in
Groovy? (They did work in Groovy 1.0.)

2. If this should work where should I start poking at the code to see what
might be causing this?

I'm willing to help, but I'd like to know if I'm barking up the wrong tree
and wasting my time (ala anonymous inner classes, never did like them). Do
you think this is a MOP issue? Is it fundamentally incompatible with the
direction of Groovy?

My use case for this is using Spring's scripting support with Groovy Beans
with Spring's AOP style transaction support, which is implemented using
proxies. I have built a rather large application using this framework over
the past year, and it works great in Groovy 1.0. I'd just like to know if
I'm facing a dead end with Groovy, and if I need to find either a non-proxy
based solution, or that I'm stuck with Groovy 1.0. (Being stuck with Groovy
1.0 really isn't a solution. I'd either have to port back to Java, or find
some other solution. I'd really rather not need to redo a years worth of
work though.)

I have posted on this issue in the user list:

http://www.nabble.com/1.1-beta-2-Dynamic-Proxy-Issue-tf4132988.html

Again any insight, ideas, conjectures, guesses... basically anything would
be appreciated. I'll work on it. I can bang rocks together.

Thanks,

Mark
--
Mark Menard
personal: http://www.vitarara.org/
business: http://www.vitarara.net/


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/24/07 2:36 PM, "Scott Hickey" <jshickey@...> wrote:

> I don't know if this is helpful but with compiled classes in my project, I'm
> pretty sure I'm not seeing this behavior with Spring. I'm using Spring AOP for
> logging and catching exceptions. I have compiled Groovy classes not managed by
> Spring that invoke methods on other compiled Groovy classes that are managed
> by Spring and I'm not seeing IllegalArgumentException. I am running into
> another problem trying to do some method logging but I don't think the problem
> in with Groovy and Spring; however I don't know *for sure* yet what the
> problem is.

Scott,

That may be of help in tracking down the issue. I will do some more testing
and see if indeed the Groovy classes are compiled ahead of time whether the
issue persists.

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/24/07 2:47 PM, "Mark Menard" <mark@...> wrote:

> On 7/24/07 2:36 PM, "Scott Hickey" <jshickey@...> wrote:
>
>> I don't know if this is helpful but with compiled classes in my project, I'm
>> pretty sure I'm not seeing this behavior with Spring. I'm using Spring AOP
>> for
>> logging and catching exceptions. I have compiled Groovy classes not managed
>> by
>> Spring that invoke methods on other compiled Groovy classes that are managed
>> by Spring and I'm not seeing IllegalArgumentException. I am running into
>> another problem trying to do some method logging but I don't think the
>> problem
>> in with Groovy and Spring; however I don't know *for sure* yet what the
>> problem is.
>
> Scott,
>
> That may be of help in tracking down the issue. I will do some more testing
> and see if indeed the Groovy classes are compiled ahead of time whether the
> issue persists.

I went back and added a compilation cycle to my tests. Running with all
groovy classes compiled to .class files makes no difference in the result.
All tests pass with Groovy 1.0, all tests fail with Groovy 1.1-beta-2.

The updated demonstration is available at:

http://mark.mjm.net/~mark/GroovyProxyTest.tar.gz

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

More information:

Proxied GroovyClass1 calls method on proxied GroovyClass2 where GroovyClass2
extends GroovyClass1 in total (ie it neither defines, nor overrides
anything) results in all tests succeeding. Does this point toward something
to look at?

Thanks,

Mark


On 7/24/07 2:22 PM, "Mark Menard" <mark@...> wrote:

> I am in the process of chasing down an issue that started when I tried to
> use 1.1-beta-2 with Spring's Groovy script support. (Not compiled scripts.)
>
> The issue seems to be that if a groovy object calls a method on another
> groovy object that is wrapped in a proxy it throws a
> "java.lang.IllegalArgumentException: object is not an instance of declaring
> class."
>
> My questions to you the developers of Groovy:
>
> 1. Is this an intended behavior? Are JDK style proxies not supported in
> Groovy? (They did work in Groovy 1.0.)
>
> 2. If this should work where should I start poking at the code to see what
> might be causing this?
>
> I'm willing to help, but I'd like to know if I'm barking up the wrong tree
> and wasting my time (ala anonymous inner classes, never did like them). Do
> you think this is a MOP issue? Is it fundamentally incompatible with the
> direction of Groovy?
>
> My use case for this is using Spring's scripting support with Groovy Beans
> with Spring's AOP style transaction support, which is implemented using
> proxies. I have built a rather large application using this framework over
> the past year, and it works great in Groovy 1.0. I'd just like to know if
> I'm facing a dead end with Groovy, and if I need to find either a non-proxy
> based solution, or that I'm stuck with Groovy 1.0. (Being stuck with Groovy
> 1.0 really isn't a solution. I'd either have to port back to Java, or find
> some other solution. I'd really rather not need to redo a years worth of
> work though.)
>
> I have posted on this issue in the user list:
>
> http://www.nabble.com/1.1-beta-2-Dynamic-Proxy-Issue-tf4132988.html
>
> Again any insight, ideas, conjectures, guesses... basically anything would
> be appreciated. I'll work on it. I can bang rocks together.
>
> Thanks,
>
> Mark

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

Mark,

My Spring config is a little different:

    <!-- compiled Groovy class -->
    <bean id="dentalRateCalc" class="rating.calc.dental.DentalRateCalc" scope="prototype"/>

    <!-- injecting method logging -->
    <aop:config proxy-target-class="true">
        <aop:pointcut id="ratingEnginePointcut" expression="execution(* rating.calc..* (..))"/>

        <aop:aspect id="methodLoggerBefore" ref="methodLogger">
            <aop:before
                pointcut-ref="ratingEnginePointcut"
                method="before"
                />
        </aop:aspect>
        .......
 
Scott

----- Original Message ----
From: Mark Menard <mark@...>
To: dev@...
Sent: Tuesday, July 24, 2007 2:15:00 PM
Subject: Re: [groovy-dev] JDK Style Proxy Issue

On 7/24/07 2:47 PM, "Mark Menard" <mark@...> wrote:

> On 7/24/07 2:36 PM, "Scott Hickey" <jshickey@...> wrote:
>
>> I don't know if this is helpful but with compiled classes in my project, I'm
>> pretty sure I'm not seeing this behavior with Spring. I'm using Spring AOP
>> for
>> logging and catching exceptions. I have compiled Groovy classes not managed
>> by
>> Spring that invoke methods on other compiled Groovy classes that are managed
>> by Spring and I'm not seeing IllegalArgumentException. I am running into
>> another problem trying to do some method logging but I don't think the
>> problem
>> in with Groovy and Spring; however I don't know *for sure* yet what the
>> problem is.
>
> Scott,
>
> That may be of help in tracking down the issue. I will do some more testing
> and see if indeed the Groovy classes are compiled ahead of time whether the
> issue persists.

I went back and added a compilation cycle to my tests. Running with all
groovy classes compiled to .class files makes no difference in the result.
All tests pass with Groovy 1.0, all tests fail with Groovy 1.1-beta-2.

The updated demonstration is available at:

http://mark.mjm.net/~mark/GroovyProxyTest.tar.gz

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

Actually my Spring configuration is very similar to what you have. But the
issue isn't Spring. I can trigger the exception without having Spring
involved at all. All it takes is a proxied groovy object calling a method on
a proxied groovy object. That's it. I'm digging into the Groovy code now.
We'll see what I come up with.

Mark


On 7/24/07 3:31 PM, "Scott Hickey" <jshickey@...> wrote:

> Mark,
>
> My Spring config is a little different:
>
>     <!-- compiled Groovy class -->
>     <bean id="dentalRateCalc" class="rating.calc.dental.DentalRateCalc"
> scope="prototype"/>
>
>     <!-- injecting method logging -->
>     <aop:config proxy-target-class="true">
>         <aop:pointcut id="ratingEnginePointcut" expression="execution(*
> rating.calc..* (..))"/>
>
>         <aop:aspect id="methodLoggerBefore" ref="methodLogger">
>             <aop:before
>                 pointcut-ref="ratingEnginePointcut"
>                 method="before"
>                 />
>         </aop:aspect>
>         .......
>  
> Scott
>
> ----- Original Message ----
> From: Mark Menard <mark@...>
> To: dev@...
> Sent: Tuesday, July 24, 2007 2:15:00 PM
> Subject: Re: [groovy-dev] JDK Style Proxy Issue
>
> On 7/24/07 2:47 PM, "Mark Menard" <mark@...> wrote:
>
>> On 7/24/07 2:36 PM, "Scott Hickey" <jshickey@...> wrote:
>>
>>> I don't know if this is helpful but with compiled classes in my project, I'm
>>> pretty sure I'm not seeing this behavior with Spring. I'm using Spring AOP
>>> for
>>> logging and catching exceptions. I have compiled Groovy classes not managed
>>> by
>>> Spring that invoke methods on other compiled Groovy classes that are managed
>>> by Spring and I'm not seeing IllegalArgumentException. I am running into
>>> another problem trying to do some method logging but I don't think the
>>> problem
>>> in with Groovy and Spring; however I don't know *for sure* yet what the
>>> problem is.
>>
>> Scott,
>>
>> That may be of help in tracking down the issue. I will do some more testing
>> and see if indeed the Groovy classes are compiled ahead of time whether the
>> issue persists.
>
> I went back and added a compilation cycle to my tests. Running with all
> groovy classes compiled to .class files makes no difference in the result.
> All tests pass with Groovy 1.0, all tests fail with Groovy 1.1-beta-2.
>
> The updated demonstration is available at:
>
> http://mark.mjm.net/~mark/GroovyProxyTest.tar.gz
>
> Thanks,
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/24/07 2:22 PM, "Mark Menard" <mark@...> wrote:

> Again any insight, ideas, conjectures, guesses... basically anything would
> be appreciated. I'll work on it. I can bang rocks together.

OK, I've been banging rock together, not too many sparks though.

I've crawled my way through ReflectionMetaMethod, MetaClassHelper, and
MetaClassImpl. Can't say I understand it all.

In ReflectionMetaMethod there are some System.out.println statements which
were commented out. I put those back in and it appears to me that my proxy
is making it all the way to that point. I added an
object.getClass().getName() call and the classname name is the generated
$Proxy1 that I'd expect.

I then walked this back into MetaClassImpl and will admit that I get a bit
lost in there. There's a lot going on, but there is nothing that seems
obviously wrong to me.

So, any help, insight, etc. would be appreciated.

Mark
--
Mark Menard
personal: http://www.vitarara.org/
business: http://www.vitarara.net/


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[graemer]

I think the problem is to do with the nature of Spring's Groovy
support. The <lang:groovy> thing uses a unique class loader per bean
definition, and what you have is something like this

Bean A

Bean B extends A

So what I think is happening is that:

Bean A is using ClassLoader A
Bean B is using ClassLoader B

Now since Bean B is using ClassLoader B it loads A into ClassLoader B
as A is its parent class. The problem is that for a class to be the
same it has to have the same class loader, however Bean A is loaded
into a ClassLoader A.

So when Bean A calls Bean B it passes the class of Bean A to Bean B
within the MOP. The problem is as far as Bean B is concerned the class
Bean A is not the same as the class which it extends (different class
loaders)

We use proxies extensively in Grails, the reason we dont have to deal
with this problem is that we use a single shared class loader

Cheers

In other words the A that B extends is loaded into ClassLoader B
whilst the A from Bean A is within ClassLoader A meaning they are not
the same class as they don't share the same class loader

On 7/25/07, Mark Menard <mark@...> wrote:

> On 7/24/07 2:22 PM, "Mark Menard" <mark@...> wrote:
>
> > Again any insight, ideas, conjectures, guesses... basically anything would
> > be appreciated. I'll work on it. I can bang rocks together.
>
> OK, I've been banging rock together, not too many sparks though.
>
> I've crawled my way through ReflectionMetaMethod, MetaClassHelper, and
> MetaClassImpl. Can't say I understand it all.
>
> In ReflectionMetaMethod there are some System.out.println statements which
> were commented out. I put those back in and it appears to me that my proxy
> is making it all the way to that point. I added an
> object.getClass().getName() call and the classname name is the generated
> $Proxy1 that I'd expect.
>
> I then walked this back into MetaClassImpl and will admit that I get a bit
> lost in there. There's a lot going on, but there is nothing that seems
> obviously wrong to me.
>
> So, any help, insight, etc. would be appreciated.
>
> Mark
> --
> Mark Menard
> personal: http://www.vitarara.org/
> business: http://www.vitarara.net/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

Mark,

It'd be interesting to have the view of the Spring guys on this, as
Graeme pointed out the problem may be lying on their side and their
integration of Groovy.


On 7/25/07, Graeme Rocher <graemerocher@...> wrote:

> I think the problem is to do with the nature of Spring's Groovy
> support. The <lang:groovy> thing uses a unique class loader per bean
> definition, and what you have is something like this
>
> Bean A
>
> Bean B extends A
>
> So what I think is happening is that:
>
> Bean A is using ClassLoader A
> Bean B is using ClassLoader B
>
> Now since Bean B is using ClassLoader B it loads A into ClassLoader B
> as A is its parent class. The problem is that for a class to be the
> same it has to have the same class loader, however Bean A is loaded
> into a ClassLoader A.
>
> So when Bean A calls Bean B it passes the class of Bean A to Bean B
> within the MOP. The problem is as far as Bean B is concerned the class
> Bean A is not the same as the class which it extends (different class
> loaders)
>
> We use proxies extensively in Grails, the reason we dont have to deal
> with this problem is that we use a single shared class loader
>
> Cheers
>
> In other words the A that B extends is loaded into ClassLoader B
> whilst the A from Bean A is within ClassLoader A meaning they are not
> the same class as they don't share the same class loader
>
> On 7/25/07, Mark Menard <mark@...> wrote:
> > On 7/24/07 2:22 PM, "Mark Menard" <mark@...> wrote:
> >
> > > Again any insight, ideas, conjectures, guesses... basically anything would
> > > be appreciated. I'll work on it. I can bang rocks together.
> >
> > OK, I've been banging rock together, not too many sparks though.
> >
> > I've crawled my way through ReflectionMetaMethod, MetaClassHelper, and
> > MetaClassImpl. Can't say I understand it all.
> >
> > In ReflectionMetaMethod there are some System.out.println statements which
> > were commented out. I put those back in and it appears to me that my proxy
> > is making it all the way to that point. I added an
> > object.getClass().getName() call and the classname name is the generated
> > $Proxy1 that I'd expect.
> >
> > I then walked this back into MetaClassImpl and will admit that I get a bit
> > lost in there. There's a lot going on, but there is nothing that seems
> > obviously wrong to me.
> >
> > So, any help, insight, etc. would be appreciated.
> >
> > Mark
> > --
> > Mark Menard
> > personal: http://www.vitarara.org/
> > business: http://www.vitarara.net/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

Graeme and Guillaume,

I would have thought that the class loaders were the cause of the issue, but
they aren't. The exact same exception is thrown even if the two objects are
instantiated using the same GCL. (Please see the latest version of the
demonstration: http://mark.mjm.net/~mark/ GroovyProxyTest.tar.gz) Also, a
related issue seems to have existed in 1.0 if the InvocationHandler was
implemented in Groovy. (cf:
http://www.nabble.com/using-MOP-to-implement-wrappers-decorators-tf3545582.h
tml#a9968363)

So, I don't really think this is a Spring issue. It really seems to be a
Groovy issue. Something changed in the 1.0 to 1.1 transition. What that
something is I really don't have much idea. I'm going to test against
1.1-beta-1 today and see if it exhibits the same error. I think I did some
time ago, got the exception and moved on figuring it would be a transient
issue that would get fixed, *doh*.

Again, thanks for the help. I do truly appreciate it.

Mark


On 7/25/07 5:07 AM, "Guillaume Laforge" <glaforge@...> wrote:

> Mark,
>
> It'd be interesting to have the view of the Spring guys on this, as
> Graeme pointed out the problem may be lying on their side and their
> integration of Groovy.
>
>
> On 7/25/07, Graeme Rocher <graemerocher@...> wrote:
>> I think the problem is to do with the nature of Spring's Groovy
>> support. The <lang:groovy> thing uses a unique class loader per bean
>> definition, and what you have is something like this
>>
>> Bean A
>>
>> Bean B extends A
>>
>> So what I think is happening is that:
>>
>> Bean A is using ClassLoader A
>> Bean B is using ClassLoader B
>>
>> Now since Bean B is using ClassLoader B it loads A into ClassLoader B
>> as A is its parent class. The problem is that for a class to be the
>> same it has to have the same class loader, however Bean A is loaded
>> into a ClassLoader A.
>>
>> So when Bean A calls Bean B it passes the class of Bean A to Bean B
>> within the MOP. The problem is as far as Bean B is concerned the class
>> Bean A is not the same as the class which it extends (different class
>> loaders)
>>
>> We use proxies extensively in Grails, the reason we dont have to deal
>> with this problem is that we use a single shared class loader
>>
>> Cheers
>>
>> In other words the A that B extends is loaded into ClassLoader B
>> whilst the A from Bean A is within ClassLoader A meaning they are not
>> the same class as they don't share the same class loader
>>
>> On 7/25/07, Mark Menard <mark@...> wrote:
>>> On 7/24/07 2:22 PM, "Mark Menard" <mark@...> wrote:
>>>
>>>> Again any insight, ideas, conjectures, guesses... basically anything would
>>>> be appreciated. I'll work on it. I can bang rocks together.
>>>
>>> OK, I've been banging rock together, not too many sparks though.
>>>
>>> I've crawled my way through ReflectionMetaMethod, MetaClassHelper, and
>>> MetaClassImpl. Can't say I understand it all.
>>>
>>> In ReflectionMetaMethod there are some System.out.println statements which
>>> were commented out. I put those back in and it appears to me that my proxy
>>> is making it all the way to that point. I added an
>>> object.getClass().getName() call and the classname name is the generated
>>> $Proxy1 that I'd expect.
>>>
>>> I then walked this back into MetaClassImpl and will admit that I get a bit
>>> lost in there. There's a lot going on, but there is nothing that seems
>>> obviously wrong to me.
>>>
>>> So, any help, insight, etc. would be appreciated.
>>>
>>> Mark
>>> --
>>> Mark Menard
>>> personal: http://www.vitarara.org/
>>> business: http://www.vitarara.net/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> http://grails.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

Some more comments:

On 7/25/07 4:51 AM, "Graeme Rocher" <graemerocher@...> wrote:

> I think the problem is to do with the nature of Spring's Groovy
> support. The <lang:groovy> thing uses a unique class loader per bean
> definition, and what you have is something like this
>
> Bean A
>
> Bean B extends A

I'm not extending any beans, simply implementing interfaces, which are
written in Java. So, the interfaces should be loaded by the parent
classloader, meaning that they would be the same, and those are the
interfaces that the Proxy would be implementing.

The structure is:

Interface JavaInteface

Groovy class A implements JavaInterface

Groovy class B implements JavaInterface

A and B are wrapped in a proxy.

A -calls-> B throws IllegalArgumentException, etc.

Now what is strange is that the following works:

SomeJavaBean -calls-> Proxied (A)

What fails is the following:

SomeJavaBean -calls-> Proxied (A) -calls-> Proxied (B)

> We use proxies extensively in Grails, the reason we dont have to deal
> with this problem is that we use a single shared class loader

Could you point me at an example of this in the Grails code? I'd like to see
how you're doing it, and how it differs from the minimalist demonstration
I've written.

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[graemer]

We use a Spring config DSL so it may not look so familiar, but for
example this class:

http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus/groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972

configures a Spring TransactionProxyFactoryBean which uses Spring AOP proxies

Cheers

On 7/25/07, Mark Menard <mark@...> wrote:

> Some more comments:
>
> On 7/25/07 4:51 AM, "Graeme Rocher" <graemerocher@...> wrote:
>
> > I think the problem is to do with the nature of Spring's Groovy
> > support. The <lang:groovy> thing uses a unique class loader per bean
> > definition, and what you have is something like this
> >
> > Bean A
> >
> > Bean B extends A
>
> I'm not extending any beans, simply implementing interfaces, which are
> written in Java. So, the interfaces should be loaded by the parent
> classloader, meaning that they would be the same, and those are the
> interfaces that the Proxy would be implementing.
>
> The structure is:
>
> Interface JavaInteface
>
> Groovy class A implements JavaInterface
>
> Groovy class B implements JavaInterface
>
> A and B are wrapped in a proxy.
>
> A -calls-> B throws IllegalArgumentException, etc.
>
> Now what is strange is that the following works:
>
> SomeJavaBean -calls-> Proxied (A)
>
> What fails is the following:
>
> SomeJavaBean -calls-> Proxied (A) -calls-> Proxied (B)
>
> > We use proxies extensively in Grails, the reason we dont have to deal
> > with this problem is that we use a single shared class loader
>
> Could you point me at an example of this in the Grails code? I'd like to see
> how you're doing it, and how it differs from the minimalist demonstration
> I've written.
>
> Thanks,
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:

> We use a Spring config DSL so it may not look so familiar, but for
> example this class:
>
> http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>
> configures a Spring TransactionProxyFactoryBean which uses Spring AOP proxies


Ok, I'll admit that that is some Groovy that is a bit over my head. (My
Groovy still looks mostly like Java, just well a little Groovier.)

Anyway, correct me if I'm wrong, but it looks to me like the only object
being wrapped in a proxy is the serviceClass. It looks to me like your
dataSource is not wrapped in a proxy. So it looks to me like you have:

SomeGroovyBean -calling-> Proxied(groovyBean) -calling-> dataSource.

In other words I think there's only one proxied bean in the chain, which
obviously works. My situation is a little different. I have two beans
wrapped in proxies A -calls-> B.

I'm going to add a test scenario that I think models your calling structure
in regards to having one proxied bean in the middle, and see if what
happens.

In other new I tested against 1.1-BETA-1 and the IllegalArgumentException is
thrown there also. So, this broke between 1.0 and 1.1.

Thanks to all for your help,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/25/07 10:40 AM, "Mark Menard" <mark@...> wrote:

>
> On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:
>
>> We use a Spring config DSL so it may not look so familiar, but for
>> example this class:
>>
>>
http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehau>>
s

>> /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>>
>> configures a Spring TransactionProxyFactoryBean which uses Spring AOP proxies
>
>
> Ok, I'll admit that that is some Groovy that is a bit over my head. (My
> Groovy still looks mostly like Java, just well a little Groovier.)
>
> Anyway, correct me if I'm wrong, but it looks to me like the only object
> being wrapped in a proxy is the serviceClass. It looks to me like your
> dataSource is not wrapped in a proxy. So it looks to me like you have:
>
> SomeGroovyBean -calling-> Proxied(groovyBean) -calling-> dataSource.
>
> In other words I think there's only one proxied bean in the chain, which
> obviously works. My situation is a little different. I have two beans
> wrapped in proxies A -calls-> B.
>
> I'm going to add a test scenario that I think models your calling structure
> in regards to having one proxied bean in the middle, and see if what
> happens.

Ok, I added the following tests:

GroovyBean -calls-> Proxied(GroovyBean) -calls-> GroovyBean = FAILURE

GroovyBean -calls-> Proxed(GroovyBean) = FAILURE

JavaBean -calls-> Proxied(GroovyBean) -calls-> GroovyBean = SUCCESS

Latest version of the demo: http://mark.mjm.net/~mark/GroovyProxyTest.tar.gz

I've started testing against beta-3-SNAPSHOT seeing as the issue exists in
betas 1 and 2. Might as well use the latest and greatest.

So, Graeme I have no idea why your code works and my test fails. Unless the
proxy that is being manufactured in the TransactionProxyFactoryBean is not
using a JDK style proxy, and is using something else. I haven't dug into
that yet. (I'm getting the last Spring source from CVS right now.)

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:

> We use a Spring config DSL so it may not look so familiar, but for
> example this class:
>
> http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>
> configures a Spring TransactionProxyFactoryBean which uses Spring AOP proxies

Graeme,

I've looked at what I think is the likely method call chain for this, and it
looks like this is probably returning a cglib proxy, rather than a JDK
dynamic proxy. Do you know which it is? Or is there a way you could add some
logging statements to determine this?

As I mentioned a short while ago someone on the Spring forum has also
mentioned that using the TransactionProxyFactoryBean methodology works fine
with the <lang:groovy> support in Spring. My suspicion is it works because
it is a cglib proxy rather than a JDK proxy.

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

I can confirm that the stuff that works for me uses cglib.
 
Scott


----- Original Message ----
From: Mark Menard <mark@...>
To: dev@...
Sent: Wednesday, July 25, 2007 12:51:47 PM
Subject: Re: [groovy-dev] JDK Style Proxy Issue


On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:

> We use a Spring config DSL so it may not look so familiar, but for
> example this class:
>
> http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>
> configures a Spring TransactionProxyFactoryBean which uses Spring AOP proxies

Graeme,

I've looked at what I think is the likely method call chain for this, and it
looks like this is probably returning a cglib proxy, rather than a JDK
dynamic proxy. Do you know which it is? Or is there a way you could add some
logging statements to determine this?

As I mentioned a short while ago someone on the Spring forum has also
mentioned that using the TransactionProxyFactoryBean methodology works fine
with the <lang:groovy> support in Spring. My suspicion is it works because
it is a cglib proxy rather than a JDK proxy.

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Menard]

On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:

> We use a Spring config DSL so it may not look so familiar, but for
> example this class:
>
> http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972

Graeme,

Could you explain the construct at line 54 in that file. I've been trying to
wrap my head around that one and I just don't get it.

Also, is a Grails serviceClass required to implement an interface? I don't
think they are, but I'm not sure. If they are not I don't think they are a
candidate for a JDK dynamic proxy, because those require that the subject of
the proxy implement at least one interface. So, that is an even stronger
indication to me that you are getting a cglib proxy.

Mark


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[graemer]

On 7/25/07, Mark Menard <mark@...> wrote:

> On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:
>
> > We use a Spring config DSL so it may not look so familiar, but for
> > example this class:
> >
> > http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> > /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>
> Graeme,
>
> Could you explain the construct at line 54 in that file. I've been trying to
> wrap my head around that one and I just don't get it.
>
> Also, is a Grails serviceClass required to implement an interface? I don't
> think they are, but I'm not sure. If they are not I don't think they are a
> candidate for a JDK dynamic proxy, because those require that the subject of
> the proxy implement at least one interface. So, that is an even stronger
> indication to me that you are getting a cglib proxy.

Yes it is a cglib proxy so that would be the reason, but it is
proxying on an interface as all Groovy objects implement the interface
groovy.lang.GroovyObject

Cheers

>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[graemer]

On 7/25/07, Mark Menard <mark@...> wrote:

> On 7/25/07 10:04 AM, "Graeme Rocher" <graemerocher@...> wrote:
>
> > We use a Spring config DSL so it may not look so familiar, but for
> > example this class:
> >
> > http://fisheye.codehaus.org/browse/grails/trunk/grails/src/groovy/org/codehaus
> > /groovy/grails/plugins/services/ServicesGrailsPlugin.groovy?r=4972
>
> Graeme,
>
> Could you explain the construct at line 54 in that file. I've been trying to
> wrap my head around that one and I just don't get it.

If you mean this one:

       "${serviceClass.propertyName}"(TransactionProxyFactoryBean) { bean ->

Its basically invoking a method using a String that takes an class and
a closure as the arguments. In Groovy you can invoke methods using
string references so this would translate into a method call like

bookService(TransactionProxyFactoryBean) { bean ->
}

The name of the method is the bean id the first argument is the bean
class. For more info see:

http://grails.codehaus.org/Spring+Bean+Builder

Cheers

>
> Also, is a Grails serviceClass required to implement an interface? I don't
> think they are, but I'm not sure. If they are not I don't think they are a
> candidate for a JDK dynamic proxy, because those require that the subject of
> the proxy implement at least one interface. So, that is an even stronger
> indication to me that you are getting a cglib proxy.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email