The Use Phase
During the use phase, all the application services in an enterprise application process the requests sent by the clients and carry out the actual application behaviors.
Listing 3-16. Getting bean using ApplicationContext in your code
|
1 2 3 4 5 6 7 |
ApplicationContext context = new ClassPathXmlApplicationContext("Test.xml"); LoyaltyService loyaltyService = context.getBean("loyaltyService"); //Now you use your servce to call the business method loyaltyService.calculateLoyaltyPointsAndCreditAccount(); |
If you are getting your raw bean (after normal instantiation using the XML configuration) from the application context, as above, there is nothing special and interesting happening. If your special BeanPostProcessor wants, however, getting beans can become more interesting. Instead of returning your raw bean as is, it can wrap your bean inside a Spring proxy, which in turn can expand the capabilities of your raw bean. As Spring revolves around the dynamic proxies for doing many of its framework-related activities, this is very important and helpful for a Spring developer. Your bean can become more powerful in your enterprise application by handing difficult application features, such as transactions and auditing.
Figure 3-7. BeanFactoryPostProcessor in action in our sample application
The Destruction Phase
In the destruction phase, all application services release any system resources already allocated and also keep the instances/objects ready to be garbage-collected. Closing the ApplicationContext triggers the destruction phase in your Spring application.
Listing 3-17. Closing ApplicationContext in your Java code
|
1 2 3 4 5 |
ApplicationContext context = new ClassPathXmlApplicationContext("Test.xml"); //Destroy the context (application) context.close(); |
The preceding routine destroys all the beans, which makes it ready to be garbage-collected and also destroys itself, meaning that you cannot use it again in your application.
When bean destruction happens, if the bean has registered itself with destruction callbacks, it will get invoked by the Spring Framework. This is usually done to explicitly release resources that the bean is holding and to perform some necessary cleaning activities.
Listing 3-18. The bean configuration in XML
|
1 2 3 4 5 6 7 |
<beans> <bean id="loyaltyService"/> <context:annotation-config/> </beans> |
An easy way to register a bean to receive destruction callbacks is to have a method annotated with the JSR-250 annotation javax.annotation.PreDestroy. Registering destruction callback using @PreDestroy annotation is done as shown in Listing 3-19.
Listing 3-19. Usage of @PreDestroy annotation in the Java method
|
1 2 3 4 5 6 7 8 9 10 11 |
public class LoyaltyServiceImpl{ @PreDestroy void release(){ //Do your resource releasing code here } } |
Using the marker interface org.springframework.beans.factory.DisposableBean is a, useful way for Spring to perform certain actions upon bean destruction. For beans implementing DisposableBean, it will run destroy() after Spring container has released the bean.
Listing 3-20. Usage of DisposableBean interface
|
1 2 3 4 5 6 7 8 9 |
public class LoyaltyServiceImpl implements DisposableBean{ public void destroy() throws Exception { System.out.println("Bean cleanup"); } } |
If you would like to register the destroy callbacks for the bean using the destroy- method, perform the actions shown in Listings 3-21 and 3-22 in XML configuration and Java code.
Listing 3-21. Usage of destroy-method attribute in XML configuration
|
1 |
<bean id="loyaltyService" destroy-method="release"/> |
Listing 3-22. Corresponding Java class to the above XML declaration
|
1 2 3 4 5 6 7 8 9 |
public class LoyaltyServiceImpl{ public void release() { System.out.println("Release/destroy method called."); } } |
Best Practice: It’s always good practice to use the init-method and destroy- method in the bean configuration file, instead of implementing the InitializingBean and DisposableBean interfaces, in order to avoid coupling your code to the Spring Framework.
Accessing Bean Instances
The simplest way of getting bean instance in your application is shown in Listing 3-23.
Listing 3-23. Getting bean instance in your Java code
|
1 2 3 |
ApplicationContext context = new ClassPathXmlApplicationContext("Test.xml"); LoyaltyService loyaltyService = context.getBean("loyaltyService"); |
If you have the type unique in your XML configuration, you can even get bean instance, as shown in Listing 3-24.
Listing 3-24. Getting bean instance in the Java class
|
1 |
LoyaltyService loyaltyService = context.getBean(LoyaltyService.class); |
[OR]
|
1 |
LoyaltyService loyaltyService = context.getBean("loyaltyService", LoyaltyService.class); |
Currently there is a debate as to whether we defeat the principle of IoC by accessing the bean in the above manner.
Another way of getting bean instances in your application is to have the autowiring automatically done by the Spring container. By doing so, you are not tying your application to Spring Framework, and this would be a better way of treating the principle of IoC rather than typing your code to the Spring container. I explain the autowiring concept in detail in subsequent chapters.
Page Visitors: 2500
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023