Listing 7.25 A Spock test for the prototype Accounts

package mjg.spring.services

import mjg.spring.entities.Account

import org.springframework.beans.factory.annotation.Autowired import org.springframework.context.ApplicationContext

import org.springframework.test.context.ContextConfiguration import org.springframework.transaction.annotation.Transactional

import spock.lang.Specification

@ContextConfiguration("classpath:applicationContext.xml")

@Transactional

class AccountSpec extends Specification { @Autowired

ApplicationContext ctx

def "prototype accounts have consecutive ids and balance 100"() { when:

Account a1 = (Account) ctx.getBean("prototypeAccount") Account a2 = (Account) ctx.getBean("prototypeAccount") Account a3 = (Account) ctx.getBean("prototypeAccount")

then:

a3.id == a2.id + 1 a2.id == a1.id + 1 a1.balance == 100.0 a2.balance == 100.0 a3.balance == 100.0

}

}

This time the application context itself is autowired into the test, because I want to call its getBean method myself multiple times. The test then gets three instances of prototypeAccount and verifies first that their account numbers are consecutive and then that all three have the expected balance.

The bottom line is that you can use Groovy to create a Spring configuration file as easily as you can use Java, and in both cases you have the full power of the language to do whatever additional configuration you might want before releasing the beans.

All of the techniques so far have discussed how to use capabilities defined in Spring. There’s one new capability, however, that allows you to define complex beans using a builder notation. This mechanism came from the Grails project but can be used anywhere.

7.6Building beans with the Grails BeanBuilder

So far in this book I haven’t said much about Grails, the powerful framework that combines Groovy DSLs with Spring MVC and Hibernate. I’ll discuss Grails much more in chapter 10 on Groovy web applications, but part of it is relevant here. Normally innovations in Spring find their way into Grails, usually in the form of a plugin, but every once in a while a Grails innovation goes the other way.

www.it-ebooks.info

The Grails BeanBuilder is an example. The grails.spring.BeanBuilder class uses Groovy’s builder syntax to create Spring configuration files. Everything you can do in regular configuration files you can do using the Grails BeanBuilder class. The best part, and the part most relevant for discussion here, is that you don’t need to be working on a Grails project to use the BeanBuilder.

NOTE Rumor has it that the Grails BeanBuilder class will be added to the core Spring libraries in version 4, which will make using it trivial. Still, the process described here is useful for any general external library.

The version of Spring used for the examples in this chapter is 3.2, which doesn’t include the BeanBuilder. A few versions ago Grails was reformulated to split its dependencies into separate JARs as much as possible, the same way Spring was refactored in version 3. The Grails distribution thus contains a JAR file called grails-spring-2.2.2.jar, corresponding to Grails version 2.2.2.

The Grails-Spring JAR could simply be added to my projects as an external JAR dependency, but because the rest of my project was built with Gradle I prefer to list my additional dependency that way too. The Grails-Spring JAR itself depends on Simple Logging Framework for Java (SLF4J), so its dependencies must be added too.

The following listing shows the complete build file, which assumes the project is using traditional Maven structure.

Listing 7.26 The complete Gradle build file, including Grails-Spring dependencies

}

www.it-ebooks.info

The additions shown in the build file are all that’s necessary to use the Grails BeanBuilder in a regular application. The Grails-Spring dependency (and SLF4J) are listed in the regular way. Any additional required JARs (and there are several) will then be downloaded automatically.

To demonstrate how to use the BeanBuilder, let me take a different approach from the earlier examples. The BeanBuilder is a class provided by an open source project. Open source projects by definition make their source code available. While browsing through the implementation of an open source project is certainly educational, I’d like to point out an oft-overlooked resource. The better open source projects are loaded with test cases. Because nobody is really fond of writing documentation,16 sometimes it’s hard to figure out exactly how to use a particular capability in a project. If you’re lucky, whoever wrote the feature you want also wrote test cases for it. Then the tests demonstrate in great detail how the feature is intended to be used. Test cases are executable documentation, illustrating the ways the author meant for you to use the feature.

In the case of the Grails BeanBuilder, there’s a test case called grails.spring

.BeanBuilderTests, which has a couple of very nice properties:

■It was originally authored by Graeme Rocher, the head of the Grails project and possibly the best developer I’ve ever met.17

■The test case has nearly 30 different tests in it, demonstrating everything you might want to do with the class.

In this section I want to review some basic features of the BeanBuilderTests class. In fact, I copied the class into the book source code just to make sure everything worked. I needed to remove a couple of tests that weren’t relevant to running BeanBuilder independently from Grails, but everything else tested successfully.

Before I continue, I should highlight this approach as a good general rule:

TEST CASES Downloading the source code of an open source project is useful even if you never look at the implementation. The test cases alone are often more valuable than the actual documentation.

That advice might be more useful than anything else said in this book. The next listing shows the first test case in the BeanBuilderTests class.

Listing 7.27 The BeanBuilderTests class with its first test case

class BeanBuilderTests extends GroovyTestCase {

void testImportSpringXml() { def bb = new BeanBuilder()

16Other than in book form, I mean. Writing books is both fun and easy. That’s my story, and I’m sticking to it.

17Except for maybe Guillaume Laforge, Dierk Koenig, Paul King, Andres Almiray, or a few others. The Groovy ecosystem is filled with wicked-smart developers.

www.it-ebooks.info

bb.beans {

importBeans "classpath:grails/spring/test.xml"

}

def ctx = bb.createApplicationContext()

def foo = ctx.getBean("foo") assertEquals "hello", foo

}

}

To use BeanBuilder all you have to do is instantiate the class. This is similar to using MarkupBuilder, SwingBuilder, AntBuilder, or any of the wide range of builders written in Groovy. Here the builder is assigned to the variable bb, so using the builder starts with bb.beans, which is like creating a root <beans> element in a Spring configuration file. The curly braces then indicate child elements. Here the child element is an importBeans element, which reads the file test.xml from the classpath. Before proceeding, here’s the text of test.xml:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="foo" class="java.lang.String"> <constructor-arg value="hello" />

</bean>

</beans>

This is a typical beans configuration file containing a single bean definition. The bean is an instance of java.lang.String whose value is hello and whose name is foo.

Returning to the test case, after importing the XML file the createApplicationContext method is invoked, which makes the beans available through the application context. Then the test calls getBean to return the foo bean and checks that its value is hello.

The conclusions to be drawn are that to use the BeanBuilder you must (1) instantiate the class, (2) define the beans using normal builder syntax, (3) create the application context from the builder, and (4) access and use the beans in the normal way.

The next listing contains another test in the test case that illustrates setting a bean’s properties.

Listing 7.28 Setting bean properties in the BeanBuilder, from BeanBuilderTests

void testSimpleBean() {

def bb = new BeanBuilder() bb.beans {

bean1(Bean1) { person = "homer" age = 45

props = [overweight:true, height:"1.8m"] children = ["bart", "lisa"]

www.it-ebooks.info

}

}

def ctx = bb.createApplicationContext()

assert ctx.containsBean("bean1") def bean1 = ctx.getBean("bean1")

assertEquals "homer", bean1.person assertEquals 45, bean1.age

assertEquals true, bean1.props?.overweight assertEquals "1.8m", bean1.props?.height assertEquals(["bart", "lisa"], bean1.children)

}

Inside the builder the syntax uses the bean name followed by the bean class in parentheses. In this case, bean1 is the name or ID of an instance of the Bean1 class. Near the bottom of the file you’ll find the definition of Bean1:

class Bean1 { String person int age Properties props List children

}

In fact, several beans are defined at the bottom of the class. Unlike Java, Groovy source files can have multiple classes defined in them. The Bean1 class contains attributes of type String, int, Properties, and List. The test case assigns the name to homer and the age to 45, uses the map syntax to assign the overweight and height properties, and sets the list to the names of the children.18 The tests then assert that the bean is in the application context and that, after retrieving it, all the properties have been set as described.

You’re not limited to defining a single bean, of course. The next listing shows a test that creates several beans and sets their relationships.

Listing 7.29 Defining several related beans with the BeanBuilder

void testBeanReferences() { def bb = new BeanBuilder() bb.beans {

homer(Bean1) { person = "homer" age = 45

props = [overweight:true, height:"1.8m"] children = ["bart", "lisa"]

}

bart(Bean1) { person = "bart" age = 11

}

lisa(Bean1) {

18 Leaving out Maggie, who sadly always seems to be an afterthought.

www.it-ebooks.info

person = "lisa" age = 9

}

marge(Bean2) { person = "marge" bean1 = homer

children = [bart, lisa]

}

}

def ctx = bb.createApplicationContext()

def homer = ctx.getBean("homer") def marge = ctx.getBean("marge") def bart = ctx.getBean("bart") def lisa = ctx.getBean("lisa")

assertEquals homer, marge.bean1 assertEquals 2, marge.children.size()

assertTrue marge.children.contains(bart) assertTrue marge.children.contains(lisa)

}

The beans named homer, bart, and lisa are all instances of the Bean1 class. The marge bean is an instance of Bean2, which adds a reference of type Bean1 called bean1. Here the bean1 reference in marge is assigned to homer. The Bean1 class also has a children attribute of type List, so it’s assigned to a list containing bart and lisa.

I don’t want to go through all the tests here, but there are a couple of features that should be highlighted. For example, you can define beans at different scopes, as shown in the next listing.

Listing 7.30 Defining beans at different scopes

void testScopes() {

def bb = new BeanBuilder() bb.beans {

myBean(ScopeTest) { bean -> bean.scope = "prototype"

}

myBean2(ScopeTest)

}

def ctx = bb.createApplicationContext()

def b1 = ctx.myBean def b2 = ctx.myBean

assert b1 != b2

b1 = ctx.myBean2

b2 = ctx.myBean2

assertEquals b1, b2

}

By setting the scope attribute on myBean to prototype, retrieving the bean twice results in separate instances. The scope of myBean2 is singleton by default, so asking for it twice results in two references to the same object.

www.it-ebooks.info

You can also use tags from different Spring namespaces. Earlier in this chapter I created an aspect using Groovy. The following listing shows a similar case using the

BeanBuilder.

Listing 7.31 Defining an aspect using BeanBuilder

void testSpringAOPSupport() {

def bb = new BeanBuilder()

bb.beans {

xmlns aop:"http://www.springframework.org/schema/aop"

fred(AdvisedPerson) { name = "Fred"

age = 45

}

birthdayCardSenderAspect(BirthdayCardSender)

aop.config("proxy-target-class":true) { aspect(id:"sendBirthdayCard",ref:"birthdayCardSenderAspect" ) {

after method:"onBirthday", pointcut:

"execution(void grails.spring.AdvisedPerson.birthday()) and this(person)"

}

}

}

def appCtx = bb.createApplicationContext() def fred = appCtx.getBean("fred") assertTrue (fred instanceof SpringProxy )

fred.birthday()

BirthdayCardSender birthDaySender = appCtx.getBean( "birthdayCardSenderAspect")

assertEquals 1, birthDaySender.peopleSentCards.size() assertEquals "Fred", birthDaySender.peopleSentCards[0].name

}

The aop namespace is declared using xmlns. In the builder that’s interpreted as a (non-existent) method call, whose interpretation is to make the namespace available under the aop prefix. The fred bean is an instance of AdvisedPerson, whose definition is

@Component(value = "person") class AdvisedPerson {

int age String name

void birthday() { ++age

}

}

www.it-ebooks.info