On 3/6/06, Chris Scott <[EMAIL PROTECTED]> wrote:
> I'm pretty sure I also agree in principle, but I think we're going to
> have to look at the changing landscape of coldfusion.
OK, I've done some analysis of the files in ColdSpring that touch
metadata and what they do with it:
AopProxyUtils:
clone()
Not clear whether this should walk the inheritance hierarchy.
Right now, no code in ColdSpring uses clone() (the AOP advice code
used to but no longer does). Since I don't know whether cloning should
handle complex objects, I don't know whether this should walk the
hierarchy but since it's unused, it can be left alone.
AutoWire:
addControllerProxy()
Obsolete.
Since nothing should now be using this, it doesn't matter whether it
walks the hierarchy or not!
BeanDefinition:
getDependencies()
Not clear that this should walk the inheritance hierarchy.
I'm not even sure yet exactly what this bit of code does. I'll revisit
this in a few days!
coldspringPlugin:
resolveDependencies()
Since the targets are listeners, plugins and filters and they
*will*
have concrete setters, this does *not* need to walk the inheritance
hierarchy.
Leave as-is, do not walk the hierarchy!
DefaultXmlBeanFactory:
constructBean()
Only touches init() - probably doesn't need to walk the
hierarchy.
If we accept that all classes should declare init() as best practice
then we can safely leave this code alone (question: what about complex
generated code where init() is inherited? That is the situation for
*some* Reactor-generated code...). Needs a little more research...
ProxyBeanFactory:
createProxyInstance()
Needs to walk hierarchy so you can proxy complex objects.
In order to proxy complex objects - like Reactor-generated gateways
etc - we need to walk the hierarchy. This is pretty clear cut so I
committed the change for this!
RemoteFactoryBean:
createRemoteProxy()
Probably should walk hierarchy.
I haven't made the change to this yet but I think it should match the
ProxyBeanFactory logic. Kurt?
ThrowsAdviceInterceptor:
buildMethods()
Use concrete types so no walking
My sense is that advice objects will be concrete, especially for
exception handling, and therefore we do not need to walk the
hierarchy.
So, in summary:
- BeanDefinition.getDependencies() - no idea, more research needed.
- DefaultXmlBeanFactory.constructBean() - more research needed (but
leaning to not changing this).
- ProxyBeanFactory.createProxyInstance() - change required (committed).
- RemoteFactoryBean.createRemoteProxy() - probably ought to match
ProxyBeanFactory.createProxyInstance().
- Others - no change needed.
--
Sean A Corfield -- http://corfield.org/
Got frameworks?
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
