The interface org.springframework.context.ApplicationContext represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the aforementioned beans. The container gets its instructions on what objects to instantiate, configure, and assemble by reading configuration metadata. The configuration metadata is represented in XML, Java annotations, or Java code.
I'm not sure I'd use the term "Spring Container". Spring actually works using a Factory. And yes, there's no real reason why you couldn't have multiple Spring factories within a single application, but it could get very messy.
On the other hand, I know a case where there are multiple Spring factories operating in a single JVM every day: A web application server, for example. Or an OSGi container. In both of these cases, one JVM hosts multiple applications, each with its own classpath. Since Spring is not provided by the container, it's up to the application to manage Spring and thus each Spring-based application in the container would have its own factory managing its own inventory of Spring Beans.
An IDE is no substitute for an Intelligent Developer.
It's a beautiful day in this neighborhood - Fred Rogers. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database