It was always that way according to FishEye:
 
http://dev.fmdrl.org:9010/viewrep/Coldspring2/coldspring/beans/DefaultXmlBeanFactory.cfc?r1=1.13&r2=1.14
 
containsBean() was checked in with that code commented out. I think there was some internal debate whether to leave AppContext and BeanFactory separate (e.g. AppContext *is* a BeanFactory with hierarchical features) or just throw the hierarchical stuff right into the default BeanFactory. Leaving them separate won out.
 
-Dave
 
On 5/5/06, Sean Corfield <[EMAIL PROTECTED]> wrote:
On 5/5/06, Ruud Hermans <[EMAIL PROTECTED]> wrote:
>  As for the second issue: I'm using the bleeding edge and I traced the cause
> of the issue.
>  The problem only occurs in subapps that use a bean which is defined in a
> parent services.xml.
>  Since the method 'containsBean' in DefaultXmlBeanFactory doesn't check its
> parent anymore (The code that does, is commented out. Another earlier
> discussion I missed? :) ), coldspringPlugin.cfc will call findBeanNameByType
> (line 162). And here is where things go wrong, since obviously the extended
> component type differs from the original component type.

I was confused to see that containsBean() *did* check its parent
because it seemed to me that was the whole point of the
ApplicationContext (which has hierarchical factories). I couldn't
understand why the regular factory did this. So, I'm not surprised
this has changed now. Um, did anyone follow that logic? :)

However, it would be nice to know *why* it was the way it was and why
it has recently changed.
--
Sean A Corfield -- http://corfield.org/
Got frameworks?

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


Reply via email to