On Mar 7, 2006, at 12:34 AM, Sean Corfield wrote:
> 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!

OK, if we leave this as it stands, I think that dependencies will be
missed for complex objects. For example, if we take an object Foo
that has an attribute bar and a setter setBar(), we have a dependency
on Bar. If we extend Foo as FooBar but don't override setBar() then
the dependency (on Bar) will not be detected by the current function.

So the question is, should we support that sort of dependency analysis?

I think we should.

> 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...

I'm inclined to leave this alone. Reactor only hits this edge case
for the "record" type which is transient and should not be managed by
ColdSpring. I think we can stand by our decision that all ColdSpring-
managed objects must declare a constructor.

> 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?

Chris agreed that this is like the
ProxyFactoryBean.createProxyInstance() case and should be modified to
walk the inheritance hierarchy.

I have made the necessary changes and committed them. ** I have not
tested this **

Please, someone who is using the RemoteFactoryBean, could you update
your code base and make sure I haven't broken anything?

Summary:

> - BeanDefinition.getDependencies() - no idea, more research needed.

I think we should modify this.

> - DefaultXmlBeanFactory.constructBean() - more research needed (but
> leaning to not changing this).

Leave alone - ColdSpring-managed objects require a constructor.

> - RemoteFactoryBean.createRemoteProxy() - probably ought to match
> ProxyBeanFactory.createProxyInstance().

Change required (committed).

Sean A Corfield
An Architect's View -- http://corfield.org/
Team Fusebox -- http://fusebox.org/
Got Gmail? -- I have 100, yes 100, invites to give away!

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

Reply via email to