How does the Bean Factory work

[Paul Crane]

Hey. I do not understand how the BeanFactory interface literally works. I know it contains 2 methods, and there're some classes that implement these, but how do they work  under the hood while compiling and what's the main difference between the ApplicationContext?

[Himai Minh]

Hi, Paul,
I hope this tutorial is helpful :
https://www.baeldung.com/spring-beanfactory

[Tim Holloway]

Basically, the BeanFactory is both a Warehouse and a Factory.

Spring references beans by the names given to them as part of their definitions, either as annotations or via a resource such as the ApplicationContext.xml file. When something asks for that bean, the Warehouse part is checked first. Warehouse is essential a Map where the bean name is the key and the bean instance is the value. If it's in-warehouse, then the bean instance is returned.

If not, the Factory part kicks in. The Factory attempts to manufacture (instantiate) an instance of the bean. If successful, the instance is stored  in the Warehouse AND returned to the requester,

Of course, there are additional complexities. The easiest way to manufacture a Bean is to invoke the no-argument constructor for that Bean (as defined, see above). However, Spring is smart, so it can also invoke constructors with arguments, as long as a suitable definition has been given.

As a side note, this is for the default case, where beans are singleton instances. You can also define a bean as multi-instance, in which case, the Warehouse isn't consulted, but instead a fresh and independent instance is manufactured for each request.

Note also that by default, beans are created on-demand, not in advance.

Next step up is the wiring mechanism, which allows Spring Bean instances to be injected as properties into other Beans. Here, too, either annotations or external definitions will guide the process. The Autowiring option allows a simplified wiring based on the idea that the name of the bean to be injected matches the property name of the target bean.

That's the essence of Spring Core. It is, of course, much more sophisticated than that, as there are other ways to provision Spring with definitions besides scanning for annotations and processing and in fact you can define your own. You can also define your own custom BeanFactory.

And finally, in common with most dual-definition systems, an explicit definition file (applicationOptions.xml) will override class annotations. That allows a bean to have reasonable defaults, but to be re-usable in other environments without modifying Java source code.

[Paul Crane]

Thank you all for the answers. However, I think I did't get it right. The BeanFactory is an interface, and the ApplicationContext is. The second one has more functionality I guess, but adds some new methods. While the runtime, the run() method works and returns the ConfigurableApplicationContext - one of the implementations of the ApplicationContext. Everybody says that the ApplicationContext is the IoC Container which contains all the beans and manages them. Where is the BeanFactory there?

[Himai Minh]

Hi, Paul,
Do you find this beanfactory vs applicationcontext helpful:
https://springframework.guru/spring-beanfactory-vs-applicationcontext/ ?

[Tim Holloway]

Both BeanFactory and ApplicationContext are Interfaces. ApplicationContext inherits from BeanFactory, and yes, it has additional powers.

Regardless, both are interfaces only, so you have to instantiate a concrete factory instance to use either one of them. Spring provides several implementation classes for that purpose. And, again, you can always implement your own if you don't like theirs.

[Paul Crane]

Okay. Logically, all parts of an application have own responsibility. The ApplicationContext contains beans, otherwise, the BeanFactory sets these? I've heard that the BeanFactory contains all the references to the beans. Is that true?

[Tim Holloway]

Contrariwise.

The Bean Factory stores/instantiates beans. The ApplicationContext contains a BeanFactory, but it adds wiring mechanisms and so forth.

[Paul Crane]

ApplicationContext is an actual working container, as far as I know. And it's used for containing all the beans. As you mentioned, the BeanFactory is a actual factory, the heart of the framework, that manages and initialize all the components. I think it also calls the *Aware classes while running(if there're any implementations, if not - then default). There's no two containers, yes?

[Himai Minh]

Hi, Paul,
You may find this tutorial helpful about ApplicationContext and BeanFactory.
https://www.baeldung.com/spring-beanfactory-vs-applicationcontext