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>
So, I thought I would revisit your suggestion whilst I await judgement on the patch...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...
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.
Is this how you would want to approach it ?
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. **********************************/
