Sean, thanks for the heads-up. I just joined the list this morning so I
didnt see your post. That being said I should have had a peek at the
archives.
Ok, I looked at ProxyFactoryBean.createProxyInstance() and its kind of
confusing. I downloaded the ColdSpring 0.5.0 Zip this morning, does it
contain the modified inheritance chain walking? From looking at whats
currently in there, it builds the Advisor chain via buildAdvisorChain()
(which walks over the array variables.interceptorNames, where does *that*
get set, I cannot see) and uses the .matches() method on the advisor chain
array element to look for a corresponding method name ... ?
Now, for objects that override each other, this probably works, but for the
objects we are using, most of them are just "shells" with no over-ridden
methods themselves and they inherit 100% of their functionality. In looking
at the above code, all it ever looks at in the meta-data structure is
"functions" and there is no look at of "extends" (so in our case there is
"functions" struct key and data).
There is so much other stuff going on in that method that its hard for me to
separate out the chain walking logic. The closest code that I have seen that
even touches the string "extends" is in AopProxyUtils.createBaseProxyBean()
and its use of reading in the contents of a CFC as a string and doing a
"Replace" for "${extends}"....
/cody
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield
Sent: Wednesday, March 08, 2006 3:29 PM
To: [email protected]
Subject: [coldspring-dev] AutoWire support extends?
On 3/8/06, Cody Caughlan <[EMAIL PROTECTED]> wrote:
> I havent actually used ColdSpring yet but I saw that it had a nifty
> object, "AutoWire" which conveniently populates an object (bean) via
> its setters using a struct and its keys as "input".
AutoWire.cfc was the original implementation of Model-Glue autowiring
- it's a Model-Glue controller. Now that Model-Glue supports autowiring
ColdSpring in its core, AutoWire.cfc is obsolete.
> However, as soon as I tried to populate a Bean which "extends" another
> Bean (and has no functions of its own, e.g. they all exist in the Base
> bean class), my method failed.
Correct. See my recent thread about walking the inheritance tree in the
archives! :)
> To support an arbitrary level
> of extends and all types of objects, I modified the method to use
> recursion
Ugh! :)
Look at how ProxyBeanFactory.createProxyInstance() does this to see a better
way to walk the inheritance tree.
> 1) Did I just re-invent the wheel? In looking at ColdSpring 0.5.0,
> AutoWire doesnt support beans which are not base beans. Is this logic
> somewhere else in the framework and I just missed it and did work for no
reason?
You missed it, see above.
> 2) If it doesnt exist, would ColdSpring benefit from me donating this
> code back to the community? Do you care or even want this?
See the recent long thread about walking the inheritance tree. We
specifically do *not* want to do this in most circumstances. I posted an
analysis on March 7th (yesterday) about this but I'll re-post here:
---------- Forwarded message ----------
From: Sean Corfield <[EMAIL PROTECTED]>
Date: Mar 7, 2006 12:02 AM
Subject: [coldspring-dev] Walking the inheritance chain...
To: [email protected]
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
