Is it proper to move the datasource and transaction manager beans up into the EAR as well? Seems a little strange, because I am using resource-ref=true, and resource references are defined to the WAR.

that remark is there to clarify that 'singleton' is not intended to mean the Gang of Four design pattern, but the default scope of a Spring bean definition. Spring cannot guarantee that only a single instance of a class exists, only that for a given bean definition defined in an ApplicationContext there's only going to be a single instance.
Without a shared parent context, using a single Spring configuration file to define multiple contexts inside of a single application would mean that a separate instance would be created for every context, whereas a single shared context will ensure that only a single instance is created. That's only important if that instance holds state that you don't want to be replicated across the contexts that make up your application, or if its creation has additional side effects that should not be repeated for every context. Think about things like caches and pools: you want the entire application to share those objects, you don't want every web module (or whatever module with its own ApplicationContext you happen to be using) to define its own instances, since that would be inefficient and potentially even problematic.

Great post even for Spring3, but I have something confused about the singleton. You mentioned"In general, if you have stateful beans that should really be used as a singleton (in the Spring sense, i.e. one instance per application as opposed to per JVM) you should define them in a single context accessed by the other contexts.", and is the comparison about the per application and per JVM means the clustered deployment and a non clustered one? If not, in a single server I think all the wars in an ear will be in a same JVM. Could you help explain that point in more details?

no, I had never anticipated that this entry would cause so much interest and feedback over the years
You say "prototypes", not sure what you mean: did you mean "profiles" perhaps? In that case it's not the same: profiles allow you to conditionally have certain beans defined depending on the profile(s) that are active when you start the ApplicationContext, this blog post talks about sharing beans from a single context across (web) modules in your application. Actually, my only other blog post which discusses environment-aware Spring applications is a way to achieve what can now be done with profiles natively in Spring 3.1.

Thank you for this excellent post and answering all those questions throughout the years. Did you have that on your mind when you were writing this blog post?

I wondered if this multiple context solution is equivalent to the use of prototypes in Spring 3? If correct wondering, which solution would you prefer?

With kind regards,

Loek

frankly I can't think of a good use case for creating a new ApplicationContext for every request. That is what you're suggesting, right? What is it exactly you're trying to achieve? Maybe using session- or request-scoped beans could help you to achieve what you want; if you have dynamic requirements for their creation then using a FactoryBean or an @Bean method on an @Configuration class might suffice.

First of all thanks for such wonderful post. I have a question related to making the same feature you are doing here session/request specific. What I am talking about is using the RequestContextListener instead of the ContextLoaderListener. Have you come across anythng like that..please guide me if you have any idea

You're explaination of the extra level of nesting using spring dispatcher servlets makes it clear now.

For the benfit of anyone else using Jetty embeded and configured with spring, one piece of the puzzle is that took me a while to discover is that the context-param needed to set the parentContextKey in a web.xml translates to an init-param in the servlet API.

ContextLoader.loadParentContext() {
[...]
String parentContextKey = servletContext.getInitParameter(LOCATOR_FACTORY_KEY_PARAM);

Here's a full Jetty example for posterity

/