application context. What is this?

Let's understand this in simple words.

The ApplicationContext is the central interface within a Spring application that is used for providing configuration information to the application. It's created when the application starts running.

It provides the entire configuration needed by our application:

1. Bean Factory - Responsible for creation of java objects called beans. One example is components in the application.
2. Application listeners - all listeners needed for events.
3. WebServer information.
4. Application current environment specific information.
5. Resource pattern resolver - resource loader with path matcher.
6. Life cycle Processor.
7. Class Loader.
8. Start and shutdown monitor.
9. Servlet Context.
10. Reader and Scanner.
11. Logger

etc.

package com.srmhitter9062.spring;
    
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
    
public class ApplicationContextUtils implements ApplicationContextAware {
    
    private static ApplicationContext ctx;
    
    @Override
    public void setApplicationContext(ApplicationContext appContext)
            throws BeansException {
        ctx = appContext;
    
    }
    
    public static ApplicationContext getApplicationContext() {
        return ctx;
    }
}

We can get some idea about the Application object in below snapshot.

In summary, we can say the Application context is a Configuration object created for application to run.

The applicationContext.xml defines the beans for the "root webapp context". It's a web aware ApplicationContext.

It is used to have beans that are shared between all servlets in a web application.

I hope this is helpful.

I guess that you colleagues meant the loaded spring application context, which allows access to:

• configuration of application,
• initialized beans,
• application events api,
• etc

@feak gives a straight answer about the meaning of ApplicationContext in terms of Spring. In short, it is an object that loads the configuration (usually a XML file annotation based) and then Spring will start managing the beans and its benefits:

• Beans declared in package
• Beans declared by annotations
• Constructor and method autowiring
• Bean injection
• Configuration, .properties and .yaml file loading
• etc

To start an application context, you may use one of the following:

• Manually load the application context at the beginning of your application. This is done for sample purposes or in standalone applications:

  public class Foo {
      public static void main(String[] args) {
          ApplicationContext context =
              new ClassPathXmlApplicationContext("path/to/applicationContext.xml");
          //use the context as you wish...
      }
  }
  

• In case of Java web applications using Spring MVC, the DispatchServlet will load the application context for you, so you only have to create a springapp-servlet.xml file in WEB-INF folder of the application.

Note that an application context is associated to a single configuration (XML based or not). Period.

---

After understanding this, you could also understand that you can have more than a single application context per application. This is, having two or more ApplicationContexts in the same application. From the last example in the console application, this is easy to check:

public class Foo {
    public static void main(String[] args) {
        ApplicationContext context =
            new ClassPathXmlApplicationContext("path/to/applicationContext.xml");
        ApplicationContext context2 =
            new ClassPathXmlApplicationContext("path/to/applicationContext.xml");
        //use the context as you wish...
    }
}

Note that we have two application contexts using the same XML configuration. Can you do this? Yes, you're actually seeing it here. What's the difference, then? The main difference is that Spring beans singleton scopes are singleton per application context, this mean when retrieving a Bar bean that's configured in applicationContext.xml file from context will not be the same as retrieving it from context2, but several retrieves from context will return the same Bar bean instance.

Is this considered a good or bad practice? Neither, it will depend on the problem to be solved (in case of last example, I would say it is a bad practice). Most people would recommend having all your beans configured in a single place (via XML or another) and loaded by a single application context.