i'm wondering why it is only possible to define a single
ApplicationContext as the parent of another one.
as far as i understand it, the main benefit with multiple
contexts is the possibility to modularize bean definitions.
sub-contexts can refer to (and even modify/override)
beans in parent contexts. that's really nice.
what i'm missing is support to inherit and use beans
from several parent contexts.
as an anology you could take the reference to classes
in jars. no one would expect that a maximum of 1
jar-reference per application module would be sufficient.
another example is OO inheritance itself, inheriting from
a single class was not enough, so (in java) interfaces
were invented to allow a form of multiple inheritance.
in my opinion the first analogy gives a better picture
of my concern, because it focuses on a deployment issue.
maybe my hazzle with the tree-like hierarchy of contexts
becomes clearer in a pluggable deployment environment.
in my case it is Eclipse with its plugins and extension points.
the pure appearance of a plugin in a special folder leads
to the start of a sub-ApplicationContext.
there frequently is the need to use several beans from
different contexts as collaborators in a "plugged" context.
at the moment i see only two possibilities to refer to such
1. via String-typed properties that are later resolved to
private bean handles by application code.
2. by letting lower contexts "inject" bean definition files
into an upper context. this way dependent code could
introduce a registry which dependent beans must
register with. beside the fact that this procedure is clumsy
in handling, it introduces severe problems with class
loading in managed environments (although it would
be possible to assemble the needed ClassLoaders
wouldn't it instead be a neat feature if i was allowed to
simply specify more than one parent context?!
i'd be pleased to open a JIRA if this feature is accepted
commonly. i'm aware that this is no simple patch ;-)