Why use Hierarchical context vs. Single context loaded with an array of 'files'

[mbayly]

Hi

Why would you choose to use a hierarchical application context over just initializing a single application context from multiple resource files (e.g. XML files)?

Still very new to Spring so forgive me if this is an obvious question. Plus I've been doing lots of reading in earlier threads about setting up hierarchical contexts etc and my bucket is somewhat full - so I'm probably just missing an obvious point.

The background to the question is that I'm building a fairly modular Eclipse RCP app and I was looking to utilize Spring to get some IOC value in there.

The modules follow a relatively well defined hierarchy with modules lower down re-using capability from modules higher up. In particular, the DAO classes of the leaf modules will need to 'inherit' JPA configuration in a core module.

When it comes to setting up the application context I think I could go two ways:

1. Have one application context in the core module that is loaded with XML files from lower down modules. The lower down module would contribute their configuration resources to the core module.

2. Have a core application context and have each module create their own application context which sets the core context as a parent.

Possibly I might run into class loader issues with (1) if the core module cannot see the leaf module classes (which might answer my question - but there are probably ways around that in Eclipse).

So what's the benefit of one approach over another?

Thanks
Martin

[Costin Leau]

There are several reasons - first it's good to split a huge XML into several pieces with focused functionality since you can manage them easily. In most cases, you apply changes on a small set of beans while the rest remain the same.
When working in a team, by dividing the big file into several chunks prevents update clashes since everyone is using, usually, a separate file.
With hierarchical appCtx you get the benefit of child/parent visibility - that is a child can see/access the beans defined in a parent ctx but not vice-versa; a parent appCtx cannot access the beans defined in a child.
This allows you to modularize your application - for example you can create one middle tier app Ctx which can serve as a parent and be shared between multiple webapp children ctxs.
The children can't communicate with one another so there is no problem of name collision or servlet mismatch while all access the common functionality provided by the parent ctx.

[pgras]

Hello,

Hierarchical application contexts is interesting to allow several web-apps to have a 'private' application context with a common middle-tier parent application context.

But to build the shared middle-tier application context you cannot easily separate it hierarchically (by modules) because an application context can only have one parent.

I also work on an application using 'modules', every module has an applicationContext-[module].xml file but doesn't instantiate an applicationContext. The final application instantiates one applicationContext using the xml files from all needed modules. (And all modules are wired together by spring

-Patrick

[nabenmir]

Hi

Here is an excellent example for Sharing a spring context across multiple Webapps that is demonstrating the power of context hierarchy

Nabil