Why should we know about Spring internals? It works! So use it and enjoy! However, as always, in order to use Spring in most efficient way, you must know, what is under the fork. Only in case you really understand its internals you will be able to use all power of Spring. You will be able to customize this framework according to challenges of your project, to achieve best performance and solve any problem without applying to Spring-support center.
During the webinar following topics were covered:
How does Spring impact the performance of your application?
What are the phases of Spring lifecycle?
What is ApplicationContext structure?
“You can’t do it with Spring!” – or maybe you can?
Our expert provided valuable information that will help people customize their Spring framework according to goals and challenges of every specific project. His insights allow Spring users to achieve better performance and solve framework issues without applying to the dedicated support center. The webinar was conducted in two distinct parts: Evgeny started by explaining all the theoretical aspects of the Spring framework and its internals. After that he moved into the practical part of the event, writing several code samples to illustrate his points. Questions & Answers
After the webinar the Q&A session took place, during which Evgeny Borisov answered some questions from the audience. Questions kept on coming even after the webinar ended, and our speaker agreed to provide answers for them:
Q: ID or name?
A: For Spring, it is the same. But ID is an xml standard, so it is limited. For example, if you want to provide several names for your bean, you can’t write: But you can also write:
Q: Will there be a default id?
A: Default id is a fully qualified name of the class. ‘#’ symbol and a number should be added after this class. For example: com.luxoft.MyService#0
Q: From the design perspective, why is it better to add the @PostConstruct annotation than to implement an interface?
A: Because @PostConstruct is a standard Java annotation from javax, and InitializingBean is a spring interface. Why create a coupling between your business class and a spring interface?
Q: Does Proxy allow proxy-only interfaces or regular classes too?
A: java.lang.reflect.Proxy allows people to create classes on the fly only according to the interface, by implementing it. If you want to create a proxy by extending from the class, you need to use CGLIB. In latest versions of Spring, the CGLIB jar was rewriting inside spring jars, so you can just use Enhancer class (very similar to Proxy.newInstance) in order to generate classes by inheritance.
Q: What library is the Proxy class from?
A: java.lang.Reflect (created in 1999)
Q: If it's prohibited by convention to override bean object in BeforeInit, then why does BeforeInit method have return type in its declaration?
A: Actually it’s for some internal Spring bean post processors. You shouldn’t replace object in PostProcessBeforeInit in order that any other bean post processor will be able to configure the object in BeforeInit Method. Think about it. If class will be replaced in the beginning and the only methods you will be able to invoke, how would you configure the object? How will you inject dependencies in private fields (in Proxy$7 class there will not be a state)? So the rule is very simple: if you want to change the object state, you will do it in PostProcessBeforeInintialization. If you want to change the behavior of the methods of the class, you will do it by replacing object with proxy in PostProcessAfterInitalization.
Q: Does multiple annotation method with PostConstruct mean that arbitrary number of methods would be invoked?
A: Yes. All of them will be invoked, and it is very dangerous to depend on the order. Nobody promises you that the order will be the same. So it is not a good idea to create more than one init method for a specific bean. Please note that init method is declared per bean, not per class. If you class extend from any other class which is not spring bean, even if Parent has method annotated with @PostConstruct it will not be init method (in contrast with @Autowired annotation). If you will use this annotation in Parent (which is not spring bean), but Son class (which is declared as spring bean) extends from Parent, the @Autowired will inject to Son bean the needed state, no matter what this field declared in Parent.