Why the complexity, you ask? My team often found the simple examples understandable, but they struggled to see the application of the monads to day-to-day business code. “Sure, we write monads that read a String from a file, chain it to monad that converts the String to Int, but we’re having to generate reports,” they said.

The service

Let’s write a ReportService that generates reports and then produces a combined report by combining the individual reports into one. Its API is:

class ReportService {

  def produce()

  def combine()

}

Where the produce function generates the individual reports (pages, if you like); and the combine function takes the already generated reports and assembles the aggregate. We keep these reports in the database (and the content on the disk) and we map the RDBMS records to the Record instances. We are using Hibernate, leading the definition of the Report class:

@Entity
case class Report() {
  @Id
  @GeneratedValue
  @BeanProperty
  var id: Long = _
  @Version
  @BeanProperty
  var version: Int = _
  @BeanProperty
  var fileName: String = _

}

As I said earlier, we are using Hibernate to manipulate the Record instances, so our ReportService will need to depend on the SessionFactory. Because we’re running in the Spring Framework, we can have the dependency injected in. We just have to give the appropriate metadata to the Spring Framework’s DI core:

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {

  def produce()

  def combine()

}

We’ll start with the produce() function. The task is to generate [a fixed number of] reports. So, we’ll need a for loop whose every iteration creates a Report instance and saves it to the DB.

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {

  @Transactional
  def produce() {
    for (i < - 0 to 100) {
      val report = Report()
      val content = "Report %d".format(i)
      report.fileName = "%d".format(i)

      // save the report's content

      sessionFactory.getCurrentSession.saveOrUpdate(report)
    }
  }

}

So far, so good. We have the fancy Scala for loop, but the code remains very similar to its Java equivalent. Now, let's deal with the IO. To save a report, we need to:

• create / open a file into which the content is going to go,
• produce the report's content,
• write the content to the file.

So, we have three operations. We go from Report to operation giving File, second that goes from operation giving File and operation giving Data to operation giving Unit. So, let's write these operations and define what we mean by Data:

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {
  type Data = Array[Char]
  import scalaz._
  import scalaz.effects._

  def reportToFile(report: Report) = io {
    new File("/Users/janmachacek/Tmp/r/%s".format(report.fileName))
  }
  def dataToFile(data: IO[Data])(file: File) = io {
    println("Written " + new String(data.unsafePerformIO) + " to " + file)
  }

  ...

}

The function reportToFile is the one that takes a Report and returns an operation that gives File. The operation that gives is whatever the io function returns. Then I have the dataToFile function that takes an operation that takes operation that gives Data and returns an operation that gives Unit. Figure 1 shows a picture of what we're trying to do.

Figure 1. The operations and the links between them



We would like to wire the three operations together to give us a new operation that combines the three together!

This is crucial concept: we're not just pushing data around, we're creating a new operation that combines the smaller operations to do something useful for us. So, let's drop in the real syntax:

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {
  type Data = Array[Char]
  import scalaz._
  import scalaz.effects._

  def reportToFile(report: Report) = io {
    new File("/Users/janmachacek/Tmp/r/%s".format(report.fileName))
  }
  def dataToFile(data: IO[Data])(file: File) = io {
    println("Written " + new String(data.unsafePerformIO) + " to " + file)
  }

  @Transactional
  def produce() {
    for (i <- 0 to 100) {
      val report = Report()
      val content = "Report %d".format(i)
      report.fileName = "%d".format(i)

      (reportToFile(report) >>=
         dataToFile(io {content.toCharArray})).unsafePerformIO

      sessionFactory.getCurrentSession.saveOrUpdate(report)
    }
  }

}

Let's explore the mystical (reportToFile(report) >>= dataToFile(io {content.toCharArray})).unsafePerformIO line. We have reportToFile takes a Report and makes a thing that makes a File. Then we have dataToFile which takes a thing that makes Data and thing that makes File. We treat these things as black boxes--they do something obscure, unknown and unknowable. But these things have a "screen" on them; and we can look at that "screen" and obtain the current value.

And that's the principle of monads. They are opaque things that can return some value and they can be chained together to form new things that combine whatever the component things do.

And that explains the unsafePerformIO call. The (reportToFile(report) >>= dataToFile(io {content.toCharArray})) simply returns a new monad, but we must "look at its screen"; make it compute a value, in other words. And that's what the unsafePerformIO function does.

Onwards, then! Let’s implement the combine function that selects all existing reports, and merges them into a one fat report that it then saves.

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {
  type Data = Array[Char]
  import scalaz._
  import scalaz.effects._
  import scala.collection.JavaConversions._

  def reportToFile(report: Report) = io {
    new File("/Users/janmachacek/Tmp/r/%s".format(report.fileName))
  }
  def dataToFile(data: IO[Data])(file: File) = io {
    println("Written " + new String(data.unsafePerformIO) + " to " + file)
  }
  def fileToData(file: File) = io {
    Source.fromFile(file).toArray
  }

  @Transactional
  def produce() {
    ...
  }

  @Transactional
  def combine() {
    val reports =
      sessionFactory.getCurrentSession.createCriteria(classOf[Report]).
        list().asInstanceOf[java.util.List[Report]].toList

    val out = Report()
    out.fileName = "out.txt"

    // take the reports and make one big fat report out

    sessionFactory.getCurrentSession.saveOrUpdate(out)
  }

}

The combine selects all Report records, and (using the function in scala.collection.JavaConversions._) converts the java.util.List[Report] into scala.collections.immutable.List[Report]. How do we now combine the reports? Let’s think about it:

• If the reports contains just one item, then the result is that one item,
• If the reports contains two items, then we need some function that takes two Reports and makes the combined Report,
• If the reports contains many (i.e. more than two!) items, then we take the first two and combine them into one (using the function from the previous step). Then we take the combined report and combine it with the third item; then we take the combined report and combine it with the fourth item; and so on, until the end.

So, we need a function that combines two reports into one and then an operation that implements the algorithm we described earlier. The name for the operation is foldl1 and Figure 2 shows how it works:

Figure 2. foldl1 function



The arrows in the image are our function and report1, report2, ..., reportn is our list. Hence the code of the combine function becomes:

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {

  ...

  @Transactional
  def combine() {
    val reports =
      sessionFactory.getCurrentSession.createCriteria(classOf[Report]).
        list().asInstanceOf[java.util.List[Report]].toList

    val out = Report()
    out.fileName = "out.txt"

    reports.foldl1 { (r1: Report, r2: Report) =>
      // read the r1 and r2 from the files,
      // combine them and write to out
      out
    }

    sessionFactory.getCurrentSession.saveOrUpdate(out)
  }
}

We now have to read the report from a file into Data and the combine the two Datas representing the reports together. The good news is that we have already written the monads that deal with the report IO. All we have to do is to combine them to form new interesting monad that combines the reports.

@Service
class ReportService @Autowired() (private val sessionFactory: SessionFactory) {

  ...

  @Transactional
  def combine() {
    val reports =
      sessionFactory.getCurrentSession.createCriteria(classOf[Report]).
        list().asInstanceOf[java.util.List[Report]].toList

    val out = Report()
    out.fileName = "out.txt"

    def combine(data: (Data, Data)) = io { data._1 ++ data._2 }

    reports.foldl1 { (r1: Report, r2: Report) =>
      (reportToFile(out) >>= dataToFile(
        (reportToFile(r1) >>= fileToData) <|*|>
        (reportToFile(r2) >>= fileToData) >>= combine)
      ).unsafePerformIO

      out
    }

    sessionFactory.getCurrentSession.saveOrUpdate(out)
  }
}

You already know about chaining the monads (using >>=), the new thing in the reports.foldl1 function is the <|*|> operation. Think of this operation indeed as multiplication, but multiplication of the computed values of the monads. The monad on the left-hand side ((reportToFile(r1) >>= fileToData)) computes Data, the monad on the right-hand side ((reportToFile(r2) >>= fileToData)) computes Data. In this case, we have Data * Data, in other words a pair–tuple in computer speak–of Data. And that’s precisely what the combine function takes (its body simply appends the two arrays) and it returns the combined IO of Data… and we can use it as input of the dataToFile function, which is an IO monad that follows the reportToFile(out) monads.

The whole contraption represents our report + report function; which we give to the foldl1 function. For completeness, we save the combined report using the injected sessionFactory.

Summary

This code combines dependency injection, load-time weaving (courtesy of the Spring Framework) with elegance and effectiveness of the Scala code. Finally, we take advantage of the IO monads in Scalaz to compose the individual trivial operations (report -> file, data -> file, etc.) to compose new operations that we use in the produce and combine functions.

SBT and DocBook

As part of our Specs2 Spring project, we wanted to ensure users had access to Spec2 Spring’s documentation in a format they know and love, we figured we’d use DocBook, the multiformat-generating, markup language.

Fortunately a SBT plugin currently exists for DocBook, however it currently doesn’t have a few features we need.

We have forked the SBT DocBook plugin, because we needed to add support for XInclude, syntax highlighting, ePUB and many other improvements. Find it here.

The Setup

Using it is pretty straight-forward. You should have a directory structure similar to this:

MyProject
  build.sbt
  src/
    main/
      java/
      scala/
      docbook/
        main.xml
        chapter1.xml
        ...
  project/
    plugins.sbt

Simply ensure all DocBook files are in the src/main/docbook directory. Note that if you have multiple DocBook files, the main file must be named main.xml. On the other hand, if there is just one file, feel free to name it anything you like.

Include the plugin in your project/plugins.sbt file as follows:

resolvers += ScalaToolsSnapshots

addSbtPlugin("de.undercouch" % "sbt-docbook-plugin" % "0.2-SNAPSHOT")

That’s it!

Run it!

Generating documents in the format of your choice is pretty easy:


$ sbt html



$ sbt pdf



$ sbt xhtml



$ sbt manpage



$ sbt eclipse-help


Checkout the readme for more options.

How have we done it?

Robust documentation is key to getting the community interested and involved in any project and modular documentation is key to the sanity of the project developers. An easy way to produce modular documentation is by using XInclude, sadly the plugin it uses, Saxon 6.5.3, for processing XSLT, cannot handle XInclude.

After extensive googling & hacking, I eventually turned to Xerces2 to resolve XInclude. The code looks a little something like this:

   private def transformDocBook(src: File, dst: File, styleSheet: String,
  cp: Classpath, log: Logger) {
    transform(src, dst, log) {
      //write output to temporary file. this avoids a bug in Saxon
      //that caused spaces in the output filename to be converted to
      //an escaped sequence (%20)
      val temp = File.createTempFile("sbt-docbook-plugin-", ".fo")
      val code = Fork.java(None, Seq[String](
      "-cp", cp.files.mkString(File.pathSeparator),
      "-Djavax.xml.parsers.DocumentBuilderFactory="+
        "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl",
      "-Djavax.xml.parsers.SAXParserFactory=" +
        "org.apache.xerces.jaxp.SAXParserFactoryImpl",
      "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=" +
        "org.apache.xerces.parsers.XIncludeParserConfiguration",
      "com.icl.saxon.StyleSheet",
      "-o", temp.toString,
        src.toString, styleSheet
      ), log)

      //copy temporary file to real output file
      temp #> dst !

      //delete temporary file (if this files it will be deleted on exit)
      if (!temp.delete()) {
        temp.deleteOnExit()
      }
      code
    }
  }

So what’s going on here? Well Fork.java makes it possible for us to run a separate java process, "-cp" sets up it’s classpath, cp.files.mkString(File.pathSeparator) ensures that the correct path separator is used for your file system, the first 2 -D options set Xerces as Saxon’s xml parser, the last -D option turns on the XInclude feature and -o set’s Saxon’s output file or directory!

Maintaining Specs2 Spring and any other documentation has been made a little easier!

The next focus will be on improving the plugin’s output for documentation split into multiple files, in particular EPUB..

New Stuff

#Scala IDE for #Eclipse 2.0.0 Release Candidate 4 available now! This release adds compatibility with Groovy IDE – in addition to lots of bug fixes and improvements.

Setak has been released! Setak is A Framework for Stepwise Deterministic Testing of Akka Actors. It allows programmers to specify the order of messages during the execution of a test. It also makes it easy to check test assertions that require actors to be in a stable state. For more information hit the link.

Stackmob is now in public beta, not much else to say on that! Click through for details.

AKKA 2.0 Milestone 1 is out now, loads of new and improved features, including:

• Modular configuration
• Mandatory Supervisor Hierarchies
• Location Transparency
• Many other additions and refinements

Click the link for more details.

AKKA 1.3-RC4 is now available to download.

Blogs and tutorials

• Havoc Pennington (@havocp) blogged about ‘Configuring the Typesafe Stack‘, covering the changes to akka.conf and Play application.conf in #playframework and #akka 2.0. Hit the link to read more.
• New post on the tech behind @klout including #playframework and #akka… ‘Akka helps Klout’s search go fast!‘
• visi.io posted an interesting blog: ‘Sweet tasty state monads‘, the title says it all – it’s well worth a look.
• Pavel Fatin (@pavelfatin) posted A couple of new Intellij IDEA blogs, Chained packages and What’s new in ScalaTest integration
• An excellent presentation by Daniel Spiewak (@djspiewak) on Functional Data Structures in Scala is now available on infoq.
• Checkout the cake blogs on Using Scala to build type-safe DSL, Pattern Matching and Spring DI vs. the Cake Pattern!
• Finally, more #Scala debates – this time a post by Nikita Ivanov of GridGain (@gridgain) discussing their experiences with the language.

Feel free to drop me a mail or message @markglh on twitter with any Scala news!

For more detailed discussion of the Cake pattern, see Mark’s Cake pattern in depth

Before we rush into condemning one or the other, we feel that what you need to think about what kind of application you’re writing. We’ll go as far as to say that if you need JMS, JMX, scheduling, WebFlow, …, then you should stick with the Spring Framework. By all means implement the components that make up your Spring application in Scala! If these JEE dinosaurs do not come anywhere near your application, then Play 2 in Scala, using the Cake pattern might just be the perfect thing for you!

Dependency injection

Spring Framework, we have multiple modules; each module contains the code that is appropriate for the tier that the module implements. The code means the Java interfaces & their implementations as well as the Spring configuration (typically in the META-INF/spring/module-context.xml file). The types of the dependencies are checked at compile-time: if we haven’t defined the UserService interface, for example, and tried to use it in the UserController, the compilation would fail. However, the compiler cannot check that the appropriate implementation of the UserService will be available to be injected to the UserController at runtime. The application is loosely coupled, which is good, but we must supply appropriate metadata (the annotations & the Spring XML) so that Spring can construct the application.

Dependency-injection applications must provide valid metadata so that the DI framework can construct their components & satisfy the dependencies between them at runtime.

Let’s write a trivial application that contains a repository and a service. We will follow the recommended code to interfaces approach. This gives us the following code in the repository:

public interface UserRepository {
  List<User> findAll();
}

@Repository
public class ORMUserRepository implements UserRepository {
  private SessionFactory sessionFactory = // construct the SF
  public List<User> findAll() {
    // not real Hibernate code, but close enough
    return sessionFactory.getCurrentSession().query(...);
  }
}

We now combine this code with the Spring context file, which instructs the DI core to create the ORMUserRepository component.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="...">

  <context:annotation-config/>
  <context:component-scan base-package="...repository"/>

<beans/>

We implement the code in the services in using a similar pattern: we have the UserService interface and we implement it in some class. Crucially, we will rely on Spring to inject a valid implementation of the UserRepository to the instance of the DefaultUserService at runtime, using the configuration we provide.

public interface UserService {
  List<User> findAll();
}

@Service
public class DefaultUserService implements UserService {
  private final UserRepository userRepository;

  @Autowired
  public DefaultUserService(final UserRepository userRepository) {
    if (userRepository == null)
      throw new IllegalArgumentException("Off Santa's list!");
    this.userRepository = userRepository;
  }

  public List<User> findAll() {
    return this.userRepository.findAll();
  }
}

The services module needs its configuration, too. And so, we give the familiar /META-INF/spring/module-context.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"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="...">

  <context:annotation-config/>
  <context:component-scan base-package="...services"/>

<beans/>

We have the components and the metadata. All we need now is to let Spring Framework create all the components. In other words, the ApplicationContext implementation that the Spring Framework provides will become our application:

public class App {

  public static void main(String[] args) {
    ApplicationContext application =
      new ClassPathXmlApplicationContext(
        "classpath*:/META-INF/spring/module-context.xml"));

    UserService service = application.getBean(UserService.class);

    // use it!
    service.findAll();
  }
}

The Spring Framework became our application! All we have is a shell that boots-up Spring, as shown on Figure 1.

Figure 1. Spring DI application

The Cake Pattern

If you are writing new Scala application, you might not want to take in all the baggage that Spring Framework brings with it. (Slf4j, anyone?)

You would typically use the Cake Pattern to achieve something akin to dependency injection. Jonas Boner explained the Cake Pattern in one of his infamous Real-World Scala Series blog post. What we would try here is to use the Cake pattern to implement the same DI scenario in Scala and then compare that with its corresponding Spring implementation. In doing that we would hope to clear out some of the misty clouds over Scala and DI.

We also want to have a repository and a service, but without the XML configuration file. So, we need not only the repository and service interfaces themselves, but we also need components in which they “live”. Starting with the repository, we have:

trait UserRepositoryComponent {
  def userRepository : UserRepository

  trait UserRepository {
    def findAll: List[User]
  }
}

trait ORMUserRepositoryComponent extends UserRepositoryComponent {
  def userRepository = new ORMUserRepository(sf) //we need to actually instantiate the session factory here

  class ORMUserRepositry(val sf: SessionFactory) extends UserRepository {
    def findAll: List[User] = sf.query(...)
  }
}

Good. We have the repository tier interface the UserRepositoryComponent provides a way to get to the UserRepository instance. We have also shown an implementation of the repository interfaces: the ORMUserRepositoryComponent‘s userRepository function gives an ORM-based implementation of the UserRepository.

Now, we would like to define the interface to the services tier:

trait UserServiceComponent {
  def userService: UserService

  trait UserService {
    def findAll: List[User]
  }
}

OK, we have the repository interface & implementation and the service interface. The implementation of the service will need to have access to some implementation of the repository interface. Naturally, we don’t want to specify which concrete repository interface implementation we want to use. In fact, we would like to let the users of our code specify arbitrary implementation of the repository interfaces. Good thing we have the composition inheritance!

trait DefaultUserServiceComponent extends UserServiceComponent {
  this: UserRepositoryComponent => 

  def userService = new DefaultUserService

  class DefaultUserService extends UserService {
    def findAll = userRepository.findAll
  }
}

Notice in particular this: UserRepositoryComponent =>. This means that the instance of DefaultUserServiceComponent depends on the UserRepositoryComponent. (It’s a little more subtle than that, but for the purposes of this post it will do.) This is in function equivalent to Spring’s @Autowired public DefaultUserService(final UserRepository userRepository). Just like the Spring application we have created, the Scala code does nothing yet. We need to wire it together in some kind of application!

object Application {
  val userServiceComponent = new DefaultUserServiceComponent with ORMUserRepositoryComponent
  val userService = userServiceComponent.userService
}

val userService = Application.userService
userService.findAll

In Scala, there is no ApplicationContext, so we have to implement our own application. But where’s the dependency injection? Here: new DefaultUserServiceComponent with ORMUserRepositoryComponent, notice the with ORMUserRepositoryComponent. Figure 2 shows the Scala application.

Figure 2. Scala DI

The comparison

As you can see, the two approaches are completely different in their implementation. DI in Spring Framework is a runtime business and the component separation is left to the way in which we structure the configuration files. DI in Scala/Cake is a compile-time business with sharper component separation. Figure 3 gives the overall comparison.

Figure 3. The big picture

Summary

As we have shown here, both pattern represent in function a kind of dependency injection & management. However, the crucial difference is that the dependency injection (in Spring Framework) is useful to manage components, leaving us to carefully design the components. The Cake Pattern allows us to inject & manage functionality. We use traits to assemble components with the functionality we require. It is a different approach to design. Let me repeat:

In plain dependency injection, we create components and we assemble these components together to form an application.
Using the Cake Pattern, we create pieces of functionality and we assemble the functionality to form the application.

Absolutely not!

Spring is still the most popular Java EE application framework; its dependency injection container allows us to combine the old-school XML with annotations and Java-based configuration. On top of the DI, there is the convenient support for dynamic AOP, data access; then we have all the enterprisey code (transaction management, scheduling, management, …). Top if off with excellent MVC implementation and in just the core of the framework, you have an excellent starting point for your applications! And that’s ignoring all the goodies in Spring Integration, Spring Batch, Spring Data, and many, many others.

But if you are keen to try something a bit more exotic, take a look at Specs2 Spring, which is the Spring Framework testing extension to the Specs2 Scala-based testing framework.

Spock Extension to simplify integration testing with Spring

The motivation for the post and the project is that most of my Spring test code was becoming too complex and–as a result–the test coverage was suffering. I was growing tired of explicit mocking and clumsy Java syntax. There had to be something better: Spock. But Spock was missing the full Spring integration I was looking for. No longer! My code at https://github.com/janm399/spock-spring-it fixes it and this post describes my motivation and the solution.

Most Spring enterprise applications use some DataSources, TransactionManagers and other JEE beasts. Now, we would like to use Spock to perform the necessary integration testing, but we don’t really want to create separate application context files for the tests.

Instead, we would like to set up the JNDI environment for the test code and use the same application context files for both testing and production. This is where this project helps: the annotations on our test classes specify the JNDI environment we wish to build for the test.

Verba docent, exempla trahunt, so I’ll start you off with a sample. Let there be:

public interface FooService {
	int x(String query);
}

@Service
@Transactional
public class DefaultFooService implements FooService {
	private HibernateTemplate hibernateTemplate;

	@Autowired
	public DefaultFooService(HibernateTemplate hibernateTemplate) {
		this.hibernateTemplate = hibernateTemplate;
	}

	public int x(String query) {
		Document d = new Document();
		d.setTitle("x");

		this.hibernateTemplate.saveOrUpdate(d);

		return query.length();
	}
}

To get this running, we give the META-INF/spring/module-context.xml configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="..."
	   xsi:schemaLocation="...">

	<context:component-scan base-package="org.spockframework.springintegration"/>

	<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/test"
		expected-type="javax.sql.DataSource"/>
	<jee:jndi-lookup id="hibernateProperties"
		jndi-name="java:comp/env/bean/hibernateProperties"
		expected-type="...HibernateProperties"/>
	<tx:jta-transaction-manager />
	<tx:annotation-driven />

	<bean id="sessionFactory"
		class="org...hibernate3.AnnotationSessionFactoryBean">
		<property name="dataSource" ref="dataSource"/>
		<property name="packagesToScan">
			<list>
				<value>org...example.domain</value>
			</list>
		</property>
		<property name="hibernateProperties"
			value="#{hibernateProperties.asProperties()}"/>
	</bean>

	<bean id="hibernateTemplate" class="org...hibernate3.HibernateTemplate">
		<property name="sessionFactory" ref="sessionFactory"/>
	</bean>

</beans>

This context file is the same for both tests and for production. The “variable” items (DataSource, TransactionManager and our custom HibernateProperties) beans are looked up from JNDI.

To the test, then. We have simply

@IntegrationTest
@ContextConfiguration(locations = "classpath*:/META-INF/spring/module-context.xml")
class FooServiceTest extends Specification {
	@Autowired
	FooService service

	def y() {
		expect:
		result == this.service.x(param)

		where:
		param	| 	result
		"one"	|	3
		"two"	|	3
		"four"	|	4
	}

}

If I wanted to have another integration test (perhaps testing another class), I would write:

@IntegrationTest
@ContextConfiguration(locations = "classpath*:/META-INF/spring/module-context.xml")
class SomeOtherServiceTest extends Specification {
	@Autowired
	SomeOtherService service

	def "testing service operation"() {
		expect:
		count = this.service.work(filter)

		where:
		filter	| 	count
		"Jan"	|	2
		"Ani"	|	1
		"Joe"	|	0
	}

}

The interesting part is the @IntegrationTest annotation. It is defined as

@Jndi(
	dataSources = @DataSource(name = "java:comp/env/jdbc/test",
		driverClass = JDBCDriver.class,
		url = "jdbc:hsqldb:mem:test"),
	mailSessions = @MailSession(name = "java:comp/env/mail/foo"),
	transactionManager =
		@TransactionManager(name = "java:comp/TransactionManager"),
	beans =
		@Bean(name = "java:comp/env/bean/hibernateProperties",
			type = HibernateProperties.class)
)
@Transactional
@TransactionConfiguration(defaultRollback = true)
@Retention(RetentionPolicy.RUNTIME)
public @interface IntegrationTest {
}

The reason why I have defined the @IntegrationTest annotation is because I want to use it on the two test classes: the FooServiceTest and SomeOtherServiceTest. Naturally, I could have used the @Jndi annotation on the test classes, but that would bring [too much] duplication.

The Spock extension understands the @Jndi annotation and its elements; it prepares the environment for the test and then executes the test in the usual Spock way.

In addition to the “webless” tests, I have now included Spring MVC web testing. This allows us to write simple
tests for our controllers; the test environment is as close to the real servlet container environment as possible. The web testing extension builds on the JNDI support and adds the @WebContextConfiguration annotation. Here is a simple
test code:

@Controller
public class IndexController {
	private ManagementService managementService;

	@Autowired
	public IndexController(ManagementService managementService) {
		this.managementService = managementService;
	}

	@RequestMapping(value = "/home/{name}", method = RequestMethod.GET)
	public String home(@PathVariable String name, Model model) {
		model.addAttribute("message", name);
		Message message = new Message();
		message.setSourceText(name);
		message.setProcessedText(name.toUpperCase());
		this.managementService.save(message);
		return "home";
	}

}

The Spock test for this simple controller is equally simple IndexControllerTest:

@WebTest
class IndexControllerTest extends WebSpecification {
	@Autowired
	def ManagementService managementService;

	def home() {
		when:
		def param = "hello"
		def wo = get("/home/%s", param)

		then:
		wo.modelAttribute("message") == param
		wo.html().contains param
		this.managementService.get(Message, 1L).sourceText == param
	}

}

The code is quite simple: we make a HTTP GET request to /hello/hello (which will execute the hello method of the IndexController). We assert that the model contains the expected attribute, that the generated HTML contains the model attribute and that the message has been persisted. To complete the picture, here’s the @WebTest annotation:

@Transactional
@TransactionConfiguration(defaultRollback = true)
@WebContextConfiguration(
	value = "/WEB-INF/sw-servlet.xml",
	contextConfiguration =
		@ContextConfiguration("classpath*:/META-INF/spring/module-context.xml")
)
@Jndi(
	dataSources = @DataSource(name = "java:comp/env/jdbc/test",
			driverClass = JDBCDriver.class, url = "jdbc:hsqldb:mem:test"),
	beans = @Bean(name = "java:comp/env/bean/hibernateProperties",
		type = HibernateProperties.class)
)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
public @interface WebTest {
}

Again, the intention of the @WebTest annotation is to allow me to re-use it on all web tests. Looking at its source, the most important annotation is the @WebContextConfiguration. It sets the name of the file from which we want to build the WebApplicationContext and sets the contextConfiguration: the location of the configuration files from which we will build the “server-side” part of our web application.

Building automatically

Now that you have the source code, we must configure Maven to include the Groovy compiler and to run all our Spock specifications as part of the tests. The configuration is actually quite simple: all we have to do is to include the appropriate build plugins. In fact, the entire portion of the build configuration is simply:

...

<build>
  <!-- Mandatory plugins for using Spock -->
  <plugins>
    <plugin>
      <groupId>org.codehaus.gmaven</groupId>
      <artifactId>gmaven-plugin</artifactId>
      <version>1.3</version>
      <configuration>
        <providerSelection>1.7</providerSelection>
      </configuration>
      <executions>
        <execution>
          <goals>
            <goal>compile</goal>
            <goal>testCompile</goal>
          </goals>
        </execution>
      </executions>
      <dependencies>
        <dependency>
          <groupId>org.codehaus.gmaven.runtime</groupId>
          <artifactId>gmaven-runtime-1.7</artifactId>
          <version>1.3</version>
          <exclusions>
            <exclusion>
              <groupId>org.codehaus.groovy</groupId>
              <artifactId>groovy-all</artifactId>
            </exclusion>
          </exclusions>
        </dependency>
        <dependency>
          <groupId>org.codehaus.groovy</groupId>
          <artifactId>groovy-all</artifactId>
          <version>1.7.5</version>
        </dependency>
      </dependencies>
    </plugin>
    <!-- Optional plugins for using Spock -->
    <plugin>
      <groupId>org.spockframework</groupId>
      <artifactId>spock-maven</artifactId>
      <version>${project.version}</version>
      <!-- you need to specify a concrete version number here -->
      <executions>
        <execution>
          <goals>
            <goal>find-specs</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

    ...
  </plugins>
</build>

...

Downloads & Summary

So, get your hands on the source code at https://github.com/janm399/spock-spring-it: it is ready to be compiled and used in your projects. A proper documentation & downloads is coming soon to http://cakesolutions.org!

It’s always good talking about jQuery as it’s relatively straight forward for the audience to read and has a shallow learning curve (if you know CSS already). One of the other pleasures talking about jQuery, and other front end tech, is that you can always show interactive demos to “wow” the audience…

Here are my slides followed by a link to my demo code:

I brought some of my demo code up to date showing examples using the live, event delegation functionality with jQuery. You can view my demo here or download it zipped here.

If you have any queries about the above or want assist you in a jQuery, Javascript and AJAX project contact us.

Spring Integration

Jonas Partner from OpenCredo also gave a presentation on the evening on Spring Integration. His slides are below:

I’m looking forward to seeing most of you again at the next Java User Group or Spring User Group event!