Re: [Springframework-developer] child context lookups

[Juergen H. <ju...@in...>]

Keith,

Do you I understand correctly that you try to look up the delegate bean -
which resides in the child context - from a delegating bean which resides in
the parent context? That won't work: If the lookup is performed within a
bean in the parent context, all it's gonna see is the parent context and the
beans there.

"Shadowing" beans with the same name does work with bean references, though.
You can for example define a bean in the child context that receives an
explicit reference to a bean of the same name in the parent context, through
a <ref parent="..."> tag which will always perform the lookup in the parent
context, thus linking to the bean there.

What exactly do you want to achieve?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Keith Donald
Sent: Friday, June 03, 2005 7:37 AM
To: spr...@li...
Subject: [Springframework-developer] child context lookups


I have a question about context hierarchy.

I've run into a situation where I have a "delegating bean" (a singleton) in
a parent context, making a lookup to a delegate instance in a flow-scoped
child context.  For transparency, the delegating bean and the delegate share
the same bean name.

This sounded fine to me, but I was greeted by a StackOverflowError within
the delegating bean implementation when it tried to lookup the delegate.
This happened because instead of getting the delegate, I got a reference
back to the delegating object itself.  In other words, when it queried the
child context, the bean in the parent was returned, not the one in the
child.  I would've thought this to be the other way around - querying the
child context would result in first its registry being checked, and then if
no bean was found a call to the parent?

Another, unreleated issue I am having is the ClasspathXmlApplicationContext
and related implementations are not serializable.  Is there any reason that
this is not supported?  In my case I have transactional state managed in a
flow-scoped context - it'd be nice if I could serialize the entire context
out for reconstruction of that state at a later point to facilitate server
restarts, for example.

Keith