BeanFactory vs ApplicationContext

In a real-time scenario, the difference between the Spring IOC Core container (BeanFactory) and Advanced J2EE container (ApplicationContext) are as follows.

1. BeanFactory will create objects for the beans (i.e., for POJO classes) mentioned in the spring.xml file (`<bean></bean>`) only when you call the .getBean() method, but whereas ApplicationContext creates the objects for all the beans (`<bean></bean>` if its scope is not explicitly mentioned as "Prototype") configured in the spring.xml while loading the spring.xml file itself.

2. BeanFactory: (Lazy container because it creates the objects for the beans only when you explicitly call from the user/main class)

/*
* Using core Container - Lazy container - Because it creates the bean objects On-Demand
*/
//creating a resource
Resource r = (Resource) new ClassPathResource("com.spring.resources/spring.xml");
//creating BeanFactory
BeanFactory factory=new XmlBeanFactory®;

//Getting the bean for the POJO class "HelloWorld.java"
HelloWorld worldObj1 = (HelloWorld) factory.getBean("test");


ApplicationContext: (Eager container because of creating the objects of all singleton beans while loading the spring.xml file itself)

ApplicationContext context = new ClassPathXmlApplicationContext("com/ioc/constructorDI/resources/spring.xml");


3. Technically, using ApplicationContext is recommended because in real-time applications, the bean objects will be created while the application is getting started in the server itself. This reduces the response time for the user request as the objects are already available to respond.

a. One difference between bean factory and application context is that former only instantiate bean when you call getBean() method while ApplicationContext instantiates Singleton bean when the container is started, It doesn't wait for getBean to be called.

b.

ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");

or


ApplicationContext context = new ClassPathXmlApplicationContext{"spring_dao.xml","spring_service.xml};

You can use one or more xml file depending on your project requirement. As I am here using two xml files i.e. one for configuration details for service classes other for dao classes. Here ClassPathXmlApplicationContext is child of ApplicationContext.

c. BeanFactory Container is basic container, it can only create objects and inject Dependencies. But we can’t attach other services like security, transaction, messaging etc. to provide all the services we have to use ApplicationContext Container.

d. BeanFactory doesn't provide support for internationalization i.e. i18n but ApplicationContext provides support for it.

e. BeanFactory Container doesn't support the feature of AutoScanning (Support Annotation based dependency Injection), but ApplicationContext Container supports.

f. Beanfactory Container will not create a bean object until the request time. It means Beanfactory Container loads beans lazily. While ApplicationContext Container creates objects of Singleton bean at the time of loading only. It means there is early loading.

g. Beanfactory Container support only two scopes (singleton & prototype) of the beans. But ApplicationContext Container supports all the beans scope.

Feature Matrix of Bean Factory vs Application Context [sourced from spring docs][1]


[![enter image description here][2]][2]

<sub>Screenshot of features of BeanFacotry and ApplicationContext</sub>


[1]:

[To see links please register here]

[2]:

I think it is worth mentioning that since Spring 3, if you want to create a factory, you can also use the [`@configuration`][1] annotation combined with the proper [`@scope`][2]

@Configuration
public class MyFactory {

@Bean
@Scope("prototype")
public MyClass create() {
return new MyClass();
}
}


Your factory should be visible by Spring container using the [`@ComponentScan`][3] annotation or xml configuration

[Spring bean scopes article from baeldung site][4]


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

[4]:

[To see links please register here]

do use BeanFactory for non-web applications because it supports only Singleton and Prototype bean-scopes.

While ApplicationContext container does support all the bean-scopes so you should use it for web applications.

To me, the primary difference to choose `BeanFactory` over `ApplicationContext` seems to be that `ApplicationContext` will pre-instantiate all of the beans. From [the *Spring* docs][1]:

> Spring sets properties and resolves dependencies as late as possible, when the bean is actually created. This means that a Spring container which has loaded correctly can later generate an exception when you request an object if there is a problem creating that object or one of its dependencies. For example, the bean throws an exception as a result of a missing or invalid property. This potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-instantiate singleton beans. At the cost of some upfront time and memory to create these beans before they are actually needed, you discover configuration issues when the ApplicationContext is created, not later. You can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated.

Given this, I initially chose `BeanFactory` for use in integration/performance tests since I didn't want to load the entire application for testing isolated beans. However -- and somebody correct me if I'm wrong -- `BeanFactory` doesn't support `classpath` XML configuration. So `BeanFactory` and `ApplicationContext` each provide a crucial feature I wanted, but neither did both.

Near as I can tell, the note in the documentation about overriding default instantiation behavior takes place in the configuration, and it's per-bean, so I can't just set the "lazy-init" attribute in the XML file or I'm stuck maintaining a version of it for test and one for deployment.

What I ended up doing was extending `ClassPathXmlApplicationContext` to lazily load beans for use in tests like so:

public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {

public LazyLoadingXmlApplicationContext(String[] configLocations) {
super(configLocations);
}

/**
* Upon loading bean definitions, force beans to be lazy-initialized.
* @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
*/

@Override
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
super.loadBeanDefinitions(reader);
for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
beanDefinition.setLazyInit(true);
}
}

}


[1]:

[To see links please register here]

In summary:

The **ApplicationContext** includes all functionality of the BeanFactory.
It is generally recommended to use the former.

There are some limited situations such as in a Mobile application, where memory consumption might be critical.

In that scenarios, It can be justifiable to use the more lightweight **BeanFactory**. However, in the most enterprise applications, the **ApplicationContext** is what you will want to use.

For more, see my blog post:

[Difference between BeanFactory and ApplicationContext in Spring – The java spring blog from the basics][1]


[1]:

[To see links please register here]

Difference between **BeanFactory** and **ApplicationContext** are following:

1. BeanFactory uses lazy initialization **but** ApplicationContext uses eager initialization. In case of BeanFactory, bean is created when you call getBeans() method, but bean is created upfront in case of ApplicationContext when the ApplicationContext object is created.
2. BeanFactory explicitly provide a resource object using syntax **but** ApplicationContext creates and manages resource objects on its own.
3. BeanFactory doesnt support internatiolization **but** ApplicationContext supports internationalization.
4. With BeanFactory annotation based dependency injection is not supported **but** annotation based dependency injection is supported in ApplicationContext.

**Using BeanFactory:**
```
BeanFactory beanfactory = new XMLBeanFactory(new FileSystemResource("spring.xml"));
Triangle triangle =(Triangle)beanFactory.getBean("triangle");
```
**Using ApplicationContext:**

```
ApplicationContext context = new ClassPathXMLApplicationContext("spring.xml")
Triangle triangle =(Triangle)context.getBean("triangle");
```

Basically we can create spring container object in two ways

1. using BeanFactory.
2. using ApplicationContext.

both are the interfaces,

using implementation classes we can create object for spring container

coming to the differences

BeanFactory :

1. Does not support the Annotation based dependency Injection.

2. Doesn't Support I18N.

3. By default its support Lazy loading.

4. it doesn't allow configure to multiple configuration files.

ex: BeanFactory context=new XmlBeanFactory(new Resource("applicationContext.xml"));

ApplicationContext

1. Support Annotation based dependency Injection.-@Autowired, @PreDestroy

2. Support I18N

3. Its By default support Aggresive loading.

4. It allow to configure multiple configuration files.

ex:
ApplicationContext context=new ClasspathXmlApplicationContext("applicationContext.xml");

I need to explain the BeanFactory & ApplicationContext.

**BeanFactory:** BeanFactory is root interface for accessing the SpringBean Container.There is basic client view of a bean container.
That interface is implemented by the object class that holds the number of beans definitions, and each uniquely identify by the String name
Depending the Bean definition the factory will return the instance that instance may be the instance of contained object or a single shared instance. Which type of instance will be return depends of bean factory configuration.
Normally Bean factory will load the all the all the beans definition, which stored in the configuration source like XML...etc.


BeanFactory is a simplest container providing the basic support for Dependency Injection

**Application Context**
Application context is a central interface with in the spring application that provide the configuration information to the application. It implements the Bean Factory Interface.

Application context is an advance container its add advance level of enterprise specific functionality such as ability to resolve the textual message from the property file....etc


An ApplicationContext provides:

Bean factory methods for accessing application components. Inherited from ListableBeanFactory.
The ability to load file resources in a generic fashion. Inherited from the ResourceLoader interface.
The ability to publish events to registered listeners. Inherited from the ApplicationEventPublisher interface.
The ability to resolve messages, supporting internationalization. Inherited from the MessageSource interface.
Inheritance from a parent context. Definitions in a descendant context will always take priority. This means, for example, that a single parent context can be used by an entire web application, while each servlet has its own child context that is independent of that of any other servlet.
In addition to standard BeanFactory lifecycle capabilities, ApplicationContext implementations detect and invoke ApplicationContextAware beans as well as ResourceLoaderAware, ApplicationEventPublisherAware and MessageSourceAware beans.