geronimo-dev mailing list archives

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

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.


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

View raw message