Groovy makes spring better, part 2nd: Changing the behavior of an application at run time

To add a dynamically refreshed bean to a Spring application with Groovy

Introduction: The Spring Framework provides a solid foundation for WEB and enterprise applications. By supporting dynamic languages such as Groovy, Spring adds features that make the application architecture more flexible and dynamic. In this 2nd and final installment of a better series of spring through Groovy, you will learn how to use a dynamically refreshed bean to change the behavior of the spring application at run time.

In part 1th of this 2-part series, you see how to use the Groovy bean to make the Spring application more flexible. Spring's groovy support enables you to use compiled or scripted groovy language beans and configure them in different ways, including using the Lang XML schema and the Grails Bean Builder. When you integrate Groovy scripts into your application, you can include additional logic in the bean creation process (for example, determining which implementation policy to use when creating a bean). You can also use different scripting Groovy beans to provide more flexibility for deployment and packaging.

Perhaps the most interesting and powerful feature of Spring's dynamic language support is the ability to monitor and detect changes to dynamic language scripts while the application is running, and automatically reload the changed bean into the Spring application context. There are a number of use cases that automatically refresh the Spring bean in a running application. Here are some examples:

PDF Generation (billing, invoices, sales reports, investment reports, receipts, schedules, etc.)

e-mail templates

Report generation

externalized business logic, specific domain language (DSL), and rule engine

System administration Tasks

Change logging level and Run-time debugging

I believe you can think of more applications. This article shows you how to add a bean refresh to a Spring application and explore how it works. The complete source code for all the examples in this article (see Downloads) is available for download.

Groovy beans that can be refreshed

In part 1th, you defined the Pdfgenerator interface and implemented it in the Groovypdfgenerator.groovy script file with a groovy Class (Groovypdfgenerator), which is located in the application's CLA In Sspath. You configured the Pdfgenerator bean based on groovy by specifying the location of the groovy script. Listing 1 shows the interface, its implementation, and the configuration using the lang XML schema:

Listing 1. Pdfgenerator interface, implementation, and configuration

//　PdfGenerator.java
public　interface　PdfGenerator　{
　　 byte[]　pdfFor(Invoice　invoice);
}

//　GroovyPdfGenerator.groovy
class　GroovyPdfGenerator　implements　PdfGenerator　{

　　 String　companyName

　　 public　byte[]　pdfFor(Invoice　invoice)　{
　　　　 ...　
　　 }

}

//　applicationContext.xml
<lang:groovy　id="pdfGenerator"
　　　　　　　 script- source="classpath:groovierspring/GroovyPdfGenerator.groovy">
　　 <lang:property　name="companyName"　value="Groovy　 Bookstore"/>
</lang:groovy>

So far, everything is fine. You have a bean named Pdfgenerator, which is implemented in Groovy, in the application CLASSPATH. When the spring application context is created, spring reads the script, compiles it into a Java class, and instantiates a groovypdfgenerator in the application context. Any other class that relies on Pdfgenerator simply declares it as a dependency, and Spring will link them together.