geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Thu, 03 Feb 2005 10:35:03 GMT
Rob Harrop wrote:

> Jules,
> I've used CGLIB extensively in Spring - you could skip this completely 
> and use Spring's AOP proxies with CGLIB underlying. This will sheild 
> you from the complexity of CGLIB and you can think in terms of 
> MethodInterceptors. If I had a choice between proxy frameworks I would 
> use AspectWerkz Proxy although I have encountered some problems on Mac 
> OS X. That said, CGLIB is perfectly fine, and the newer version (2.1) 
> has some important bug fixes in it. If you need help building a proxy 
> implementation using CGLIB drop me a line, but I think it would be 
> easier to use Spring's AOP proxies.
> Rob

I've had a chat with Rob and it looks like any form of proxying that 
uses subclassing is out, because Spring may return a cglib proxy with 
final methods on it.

The best candidate at the moment seems to be 
net.sf.cglib.proxy.InterfaceMaker - missed on my first sweep because the 
doc at is out of date...

I'll hold off on messing around with this for a while...


> Jules Gosnell wrote:
>> <stuff deleted>
>>>> The plan for integrating component frameworks such as spring is to 
>>>> write a GBean component that holds the spring object delegates 
>>>> method calls to it.  Yes this is another layer of indirection, but 
>>>> it can be made very fast.  This way, spring can handle construction 
>>>> and your GBean component simply wraps it.
>>> So, given that the Spring component might be any POJO, this GBean 
>>> (except that it doesn't have to be a GBean , only implement 
>>> GBeanLifecycle, and it doesn't even seem to have to do that, as the 
>>> kernel uses an instanceof test before calling lifecycle methods - 
>>> only at a swift glance) needs to be either the POJO itself, or some 
>>> form of engineered proxy, since we cannot be sure that the POJO 
>>> implements an interface that we can 1.3-proxy. Regardless of which, 
>>> we still need a way to push this instance into the kernel so it can 
>>> be given to the proxy...
>>> Is this how you would want to approach it ?
>> So, I thought I would revisit your suggestion whilst I await 
>> judgement on the patch...
>> The only way I can see this working, is for me to find some way of 
>> dynamically generating a proxy class that duplicates all methods on 
>> my POJO and delegates any call to them to the POJO. The POJO would 
>> have to be injected at construction time, as the Proxy does not want 
>> to start adding accessors (e.g. setPOJO()) in case they collide with 
>> methods already present in the POJO.
>> So, I need a ProxyClass that I can pass in to the kernel along with 
>> the POJO and enough metadata that the kernel can understand how to 
>> inject it into a fresh instance of the class. Then everything would 
>> work as planned. Only I see no benefit in having a proxy here :-). I 
>> am not intercepting anything - it is simply complex syntactic sugar 
>> to avoid making a change to the kernel...
>> I've had a look at cglib, in an effort to find a way of creating such 
>> a proxy - there seem to be 3 promising avenues - Proxy (interfaces 
>> only), Enhancer (no final methods) and Mixin, which I am trying to 
>> grok at the moment...
>> I could do with some guidance here. Have I correctly understood what 
>> you are suggesting, or am I off on a time-wasting tangent ? If so, 
>> what did you mean ? If not, do you think this is achievable with 
>> proxying technology - which one ?
>> Cheers,
>> Jules
>>> Jules
>>>> -dain

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message