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 http://cglib.sourceforge.net/apidocs is out of date...
I'll hold off on messing around with this for a while...
Jules
>
> 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)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
|