BeanFactory vs ApplicationContext

I'm pretty new to the Spring Framework, I've been playing around with it and putting a few samples apps together for the purposes of evaluating Spring MVC for use in an upcoming company project. So far I really like what I see in Spring MVC, seems very easy to use and encourages you to write classes that are very unit test-friendly.

Just as an exercise, I'm writing a main method for one of my sample/test projects. One thing I'm unclear about is the exact differences between `BeanFactory` and `ApplicationContext` - which is appropriate to use in which conditions?

I understand that `ApplicationContext` extends `BeanFactory`, but if I'm just writing a simple main method, do I need the extra functionality that `ApplicationContext` provides? And just exactly what kind of extra functionality does `ApplicationContext` provide?

In addition to answering "which should I use in a main() method", are there any standards or guidelines as far as which implementation I should use in such a scenario? Should my main() method be written to depend on the bean/application configuration to be in XML format - is that a safe assumption, or am I locking the user into something specific?

And does this answer change in a web environment - if any of my classes needed to be aware of Spring, are they more likely to need `ApplicationContext`?

Thanks for any help. I know a lot of these questions are probably answered in the reference manual, but I'm having a hard time finding a clear breakdown of these two interfaces and the pros/cons of each without reading thru the manual with a fine-tooth comb.

The spring docs are great on this: [3.8.1. BeanFactory or ApplicationContext?][1].
They have a table with a comparison, I'll post a snippet:

**Bean Factory**

- Bean instantiation/wiring

**Application Context**

- Bean instantiation/wiring
- Automatic BeanPostProcessor registration
- Automatic BeanFactoryPostProcessor registration
- Convenient MessageSource access (for i18n)
- ApplicationEvent publication

So if you need any of the points presented on the Application Context side, you should use ApplicationContext.


[1]:

[To see links please register here]

To add onto what Miguel Ping answered, here is [another section from the documentation][1] that answers this as well:

>Short version: use an ApplicationContext unless you have a really good reason for not doing so. For those of you that are looking for slightly more depth as to the 'but why' of the above recommendation, keep reading.

(posting this for any future Spring novices who might read this question)


[1]:

[To see links please register here]

For the most part, ApplicationContext is preferred unless you need to save resources, like on a mobile application.

I'm not sure about depending on XML format, but I'm pretty sure the most common implementations of ApplicationContext are the XML ones such as ClassPathXmlApplicationContext, XmlWebApplicationContext, and FileSystemXmlApplicationContext. Those are the only three I've ever used.

If your developing a web app, it's safe to say you'll need to use XmlWebApplicationContext.

If you want your beans to be aware of Spring, you can have them implement BeanFactoryAware and/or ApplicationContextAware for that, so you can use either BeanFactory or ApplicationContext and choose which interface to implement.

I think it's better to always use ApplicationContext, unless you're in a mobile environment like someone else said already. ApplicationContext has more functionality and you definitely want to use the PostProcessors such as RequiredAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor and CommonAnnotationBeanPostProcessor, which will help you simplify your Spring configuration files, and you can use annotations such as @Required, @PostConstruct, @Resource, etc in your beans.

Even if you don't use all the stuff ApplicationContext offers, it's better to use it anyway, and then later if you decide to use some resource stuff such as messages or post processors, or the other schema to add transactional advices and such, you will already have an ApplicationContext and won't need to change any code.

If you're writing a standalone app, load the ApplicationContext in your main method, using a ClassPathXmlApplicationContext, and get the main bean and invoke its run() (or whatever method) to start your app. If you're writing a web app, use the ContextLoaderListener in web.xml so that it creates the ApplicationContext and you can later get it from the ServletContext, regardless of whether you're using JSP, JSF, JSTL, struts, Tapestry, etc.

Also, remember you can use multiple Spring configuration files and you can either create the ApplicationContext by listing all the files in the constructor (or listing them in the context-param for the ContextLoaderListener), or you can just load a main config file which has import statements. You can import a Spring configuration file into another Spring configuration file by using <import resource="otherfile.xml" /> which is very useful when you programmatically create the ApplicationContext in the main method and load only one Spring config file.

**ApplicationContext:**
It loads spring beans configured in spring configuration file,and manages the life cycle of the spring bean as and WHEN CONTAINER STARTS.It won't wait until **getBean("springbeanref")** is called.

**BeanFactory**
It loads spring beans configured in spring configuration file,manages the life cycle of the spring bean when we call the **getBean("springbeanref")**.So when we call the **getBean("springbeanref")** at the time of spring bean life cycle starts.

1. `ApplicationContext` is more preferred way than `BeanFactory`

2. In new Spring versions `BeanFactory` is replaced with `ApplicationContext`. But still `BeanFactory` exists for backward compatability
3. `ApplicationContext extends BeanFactory` and has the following benefits
- it supports internationalization for text messages
- it supports event publication to the registered listeners
- access to the resources such as URLs and files

Refer this doc from Spring Docs:

<a href="http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-introduction-ctx-vs-beanfactory">

[To see links please register here]

</a>


5.15.1 BeanFactory or ApplicationContext?

Use an ApplicationContext unless you have a good reason for not doing so.

Because the ApplicationContext includes all functionality of the BeanFactory, it is generally recommended over the BeanFactory, except for a few situations such as in an Applet where memory consumption might be critical and a few extra kilobytes might make a difference. However, for most typical enterprise applications and systems, the ApplicationContext is what you will want to use. Spring 2.0 and later makes heavy use of the BeanPostProcessor extension point (to effect proxying and so on). If you use only a plain BeanFactory, a fair amount of support such as transactions and AOP will not take effect, at least not without some extra steps on your part. This situation could be confusing because nothing is actually wrong with the configuration.

ApplicationContext is a big brother of BeanFactory and this would all thing that BeanFactory are provide plus many other things.

In addition to standard org.springframework.beans.factory.BeanFactory lifecycle capabilities, ApplicationContext implementations detect and
invoke ApplicationContextAware beans as well as ResourceLoaderAware, ApplicationEventPublisherAware and MessageSourceAware beans.

**BeanFactory** and **ApplicationContext** both are ways to get beans from your spring **IOC** container but still there are some difference.

**BeanFactory** is the actual container which instantiates, configures, and manages a number of bean's. These beans are typically collaborate with one another, and thus have dependencies between themselves. These dependencies are reflected in the configuration data used by the BeanFactory.

**BeanFactory** and **ApplicationContext** both are Java interfaces and ApplicationContext extends BeanFactory. Both of them are configuration using XML configuration files. In short BeanFactory provides basic Inversion of control(**IoC**) and Dependency Injection (**DI**) features while ApplicationContext provides **advanced** features.

A BeanFactory is represented by the interface "**org.springframework.beans.factory**" Where BeanFactory, for which there are multiple implementations.

ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);

**DIFFERENCE**

1. **BeanFactory** instantiate bean when you call **getBean()** method while ApplicationContext instantiate Singleton bean when container is started, It doesn't wait for getBean() to be called.

2. **BeanFactory** doesn't provide support for internationalization but **ApplicationContext** provides support for it.

3. Another difference between **BeanFactory** vs **ApplicationContext** is ability to publish event to beans that are registered as listener.

4. One of the popular implementation of **BeanFactory** interface is **XMLBeanFactory** while one of the popular implementation of **ApplicationContext** interface is **ClassPathXmlApplicationContext**.

5. If you are using auto wiring and using **BeanFactory** than you need to register **AutoWiredBeanPostProcessor** using API which you can configure in XML if you are using **ApplicationContext**. In summary **BeanFactory** is OK for testing and non production use but **ApplicationContext** is more feature rich container implementation and should be favored over **BeanFactory**

6. **BeanFactory** by default its support **Lazy** loading and **ApplicationContext** by default support **Aggresive** loading.