DDevelopment & Design

Spring Boot and AngularJS quick start

In this post I am going to show very simple and quick example of web application using Spring Boot with AngularJS. This app contains simple functionality of sending and storing imaginary messages. I’ve also used gradle for build management. All code is…
In this post I am going to show very simple and quick example of web application using Spring Boot with AngularJS. This app contains simple functionality of sending and storing imaginary messages. I’ve also used gradle for build management. All code is public and it is available on my github: https://github.com/rafalnowak/spring-boot-fun

Introduction to Spring Boot

Spring Boot is quite new project created under Spring Source umbrella. It was very few months ago when it reached version 1.0 and status of general availability.
Most important and prominent goals of this projects are:
  • providing ability to create simple web apps very quickly
  • minimizing amount of XML codebloat which is usually necessary to configure every Spring application
  • most of app configuration is automatical
  • simplify running and deployment process by using embedded Tomcat or Jetty servers that can run our applications without special effort and deploy process
  • there are lot of so called spring boot starters which are packages containing default configuration for various fields of Spring like database access by JPA, aspect oriented programming or security
As we can see, it looks promising. In this post I’ll show few basic steps necessary to create and boot simple Spring Boot web application.

First steps

Although Spring Boot can be used with special command line interface tools, I’ve decided to use it with very popular gradle build system.
Spring Boot comes with plugins to integrate with maven or gradle. They allow us to easily run application in embedded server. Necessary instructions to include these plugin are shown on snippet below: 
buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:1.0.1.RELEASE")
    }
}
With this basic config we can proceed to next steps. In my sample project I’ve divided application into two modules: one contains persistence layer with domain object and JPA repositories and another contains presentation layer with controllers. Of course this completely optional and in such simple project it does not add any benefits. But it can show how to create multi module project in gradle. Next code fragment contains common configuration for all modules in our gradle build: 
allprojects {
    apply plugin: "java"

    version = '1.0-SNAPSHOT'
    group = "info.rnowak.springBootFun"

    repositories {
        mavenLocal()
        mavenCentral()
    }

    dependencies {
        compile "org.springframework.boot:spring-boot-starter-test:1.0.1.RELEASE"
        compile "com.google.guava:guava:16.0.1"
        compile "com.h2database:h2:1.3.175"

        testCompile "junit:junit:4.11"
        testCompile "org.mockito:mockito-all:1.9.5"
        testCompile "org.assertj:assertj-core:1.5.0"
    }
}

Now when we have common configuration, we can declare basic modules of application: 

project(":persistence") {
    dependencies {
        compile "org.springframework.boot:spring-boot-starter-data-jpa:1.0.1.RELEASE"

        testCompile project(":webapp")
    }
}

project(":webapp") {
    apply plugin: "spring-boot"

    dependencies {
        compile project(":persistence")
        compile "org.springframework.boot:spring-boot-starter-web:1.0.1.RELEASE"
    }
}
Most important parts are including special Spring Boot Starter packages and declaring usage of spring-boot plugin in one of subprojects.
Every starter packet contains dependencies for all necessary libraries used on given feature. For example, JPA starter has Hibernate dependencies and AOP starter contains spring-aop and AspectJ libraries. What is more, with this libraries Spring Boot provides also default configuration.
It is simple quick start configuration but it is enough for some starter applications.

Let’s start fun with Spring!

Our next step should be creating of starting point of application. With Spring Boot it can be done by writing regular main method in some class. Now you only need to annotate this class with special Spring Boot auto configuration annotations and application is ready to run! Example of start class is shown below: 
package info.rnowak.springFun;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.ComponentScan;

@ComponentScan
@EnableAutoConfiguration
public class SpringFun {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(SpringFun.class);
        app.setShowBanner(false);
        app.run(args);
    }
}
Well, this step look simple but it has few interesting implications for all application.
Firstly, this class enables component scan for Spring managed beans with root package info.rnowak.springFun because it is placed in this package.
Another thing is that this main method allows to run application using command gradle run. By default it uses embedded Tomcat running on port 8080. Of course this behaviour can be changed and it is very well described in project documentation. It is also possible to create runnable jar from our application.
With main class defined we can create all other classes in our application like controllers, repositories, domain classes or services. But I won’t show exact examples of such classes because they do not differ in any way from the same classes in old classic Spring. If you are interesed in my example, please take a look at the repository Spring Boot Fun repo.

Add some AngularJS

One of another “side effect” of Spring Boot main configuration class is that we get few default view resolvers. View resolver, in short version, is Spring feature, which maps names of view to specific view files.
Spring Boot with its default configuration sets lookup path for index.html file which will be served by default controller. Framework looks for this file in public/, webapp/ or resources/ directory on classpath. So you can just put index.html file in one of these locations and Spring Boot will create controller serving this view. And this is the way we can use AngularJS in our project. Of course it’s not the only way but it is the simplest method for using AngularJS with Spring Boot application.
In our example application index.html file was placed in webapp/ directory and it looks like this: 
<!DOCTYPE html>

<html ng-app="springFun">

<head>
    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css">

    <script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
    <script src="//netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js"></script>

    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-beta.4/angular.min.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-beta.4/angular-route.min.js"></script>
    <script src="js/application.js"></script>
    <script src="js/controllers.js"></script>
</head>

<body>

    <nav class="navbar navbar-default" role="navigation">
        <div class="container-fluid">
            <div class="navbar-header">
                <a class="navbar-brand" href="#/index">Spring Boot Fun</a>
            </div>
            <div class="collapse navbar-collapse">
                <ul class="nav navbar-nav">
                    <li><a href="#/list">Messages list</a></li>
                    <li><a href="#/about">About</a></li>
                </ul>
            </div>
        </div>
    </nav>

    <div ng-view></div>

    <footer class="text-center">
        Spring Boot Fun
    </footer>

</body>

</html>
This file includes all angular libraries used in project, controllers definition and main application module with routing defined.
The rest of files is available in repository mentioned earlier in post so I will not provide all listings here as it would be just waste of virtual space in post :)

Summary

As we can see, Spring Boot greatly decreases time needed to write and run simple Java web application. It reduces amount of XML configuration and provieds a lot of default values and conventions. But if we want to precisely set some settings, Spring Boot does not forbid it and programmer can manually set all the settings.
Also deploy of application is simplified because Spring Boot with gradle or maven plugin allows to run application in place with these tools. We can also create runnable jar that contains embedded Tomcat or Jetty. And if it is not desired by us, we can always use war plugin and create regular, traditional war and deploy it in classical way.
Spring Boot has also great documentation and I strongly encourage to read it by everybody interested in this tool: Spring Boot Docs

— Previous article

Meet Sputnik - static code analyser for Gerrit

Next article —

Hello 33rd Degree Conference

You May Also Like
DDevelopment & Design

Integration testing custom validation constraints in Jersey 2

I recently joined a team trying to switch a monolithic legacy system into set of RESTful services in Java. They decided to use latest 2.x version of Jersey as a REST container which was not a first choice for me, since I’m not a big fan of JSR-* specs. But now I must admit that JAX-RS 2.x is doing things right: requires almost zero boilerplate code, support auto-discovery of features and prefers convention over configuration like other modern frameworks. Since the spec is still young, it’s hard to find good tutorials and kick-off projects with some working code. I created jersey2-starter project on GitHub which can be used as starting point for your own production-ready RESTful service. In this post I’d like to cover how to implement and integration test your own validation constraints of REST resources.

Custom constraints

One of the issues which bothers me when coding REST in Java is littering your class model with annotations. Suppose you want to build a simple Todo list REST service, when using Jackson, validation and Spring Data, you can easily end up with this as your entity class:

@Document
public class Todo {
    private Long id;
    @NotNull
    private String description;
    @NotNull
    private Boolean completed;
    @NotNull
    private DateTime dueDate;

    @JsonCreator
    public Todo(@JsonProperty("description") String description, @JsonProperty("dueDate") DateTime dueDate) {
        this.description = description;
        this.dueDate = dueDate;
        this.completed = false;
    }
    // getters and setters
}

Your domain model is now effectively blured by messy annotations almost everywhere. Let’s see what we can do with validation constraints (@NotNulls). Some may say that you could introduce some DTO layer with own validation rules, but it conflicts for me with pure REST API design, which stands that you operate on resources which should map to your domain classes. On the other hand - what does it mean that Todo object is valid? When you create a Todo you should provide a description and due date, but what when you’re updating? You should be able to change any of description, due date (postponing) and completion flag (marking as done) - but you should provide at least one of these as valid modification. So my idea is to introduce custom validation constraints, different ones for creation and modification: 

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForCreation.Validator.class)
public @interface ValidForCreation {
    //...
    class Validator implements ConstraintValidator<ValidForCreation, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && todo.getDescription() != null
                && todo.getDueDate() != null;
        }
    }
}

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForModification.Validator.class)
public @interface ValidForModification {
    //...
    class Validator implements ConstraintValidator<ValidForModification, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && (todo.getDescription() != null || todo.getDueDate() != null || todo.isCompleted() != null);
        }
    }
}

And now you can move validation annotations to the definition of a REST endpoint:

@POST
@Consumes(APPLICATION_JSON)
public Response create(@ValidForCreation Todo todo) {...}

@PUT
@Consumes(APPLICATION_JSON)
public Response update(@ValidForModification Todo todo) {...}

And now you can remove those NotNulls from your model.

Integration testing

There are in general two approaches to integration testing:

  • test is being run on separate JVM than the app, which is deployed on some other integration environment
  • test deploys the application programmatically in the setup block.

Both of these have their pros and cons, but for small enough servoces, I personally prefer the second approach. It’s much easier to setup and you have only one JVM started, which makes debugging really easy. You can use a generic framework like Arquillian for starting your application in a container environment, but I prefer simple solutions and just use emdedded Jetty. To make test setup 100% production equivalent, I’m creating full Jetty’s WebAppContext and have to resolve all runtime dependencies for Jersey auto-discovery to work. This can be simply achieved with Maven resolved from Shrinkwrap - an Arquillian subproject: 

    WebAppContext webAppContext = new WebAppContext();
    webAppContext.setResourceBase("src/main/webapp");
    webAppContext.setContextPath("/");
    File[] mavenLibs = Maven.resolver().loadPomFromFile("pom.xml")
                .importCompileAndRuntimeDependencies()
                .resolve().withTransitivity().asFile();
    for (File file: mavenLibs) {
        webAppContext.getMetaData().addWebInfJar(new FileResource(file.toURI()));
    }
    webAppContext.getMetaData().addContainerResource(new FileResource(new File("./target/classes").toURI()));

    webAppContext.setConfigurations(new Configuration[] {
        new AnnotationConfiguration(),
        new WebXmlConfiguration(),
        new WebInfConfiguration()
    });
    server.setHandler(webAppContext);

(this Stackoverflow thread inspired me a lot here)

Now it’s time for the last part of the post: parametrizing our integration tests. Since we want to test validation constraints, there are many edge paths to check (and make your code coverage close to 100%). Writing one test per each case could be a bad idea. Among the many solutions for JUnit I’m most convinced to the Junit Params by Pragmatists team. It’s really simple and have nice concept of JQuery-like helper for creating providers. Here is my tests code (I’m also using builder pattern here to create various kinds of Todos):

@Test
@Parameters(method = "provideInvalidTodosForCreation")
public void shouldRejectInvalidTodoWhenCreate(Todo todo) {
    Response response = createTarget().request().post(Entity.json(todo));

    assertThat(response.getStatus()).isEqualTo(BAD_REQUEST.getStatusCode());
}

private static Object[] provideInvalidTodosForCreation() {
    return $(
        new TodoBuilder().withDescription("test").build(),
        new TodoBuilder().withDueDate(DateTime.now()).build(),
        new TodoBuilder().withId(123L).build(),
        new TodoBuilder().build()
    );
}

OK, enough of reading, feel free to clone the project and start writing your REST services!

I recently joined a team trying to switch a monolithic legacy system into set of RESTful services in Java. They decided to use latest 2.x version of Jersey as a REST container which was not a first choice for me, since I’m not a big fan of JSR-* specs. But now I must admit that JAX-RS 2.x is doing things right: requires almost zero boilerplate code, support auto-discovery of features and prefers convention over configuration like other modern frameworks. Since the spec is still young, it’s hard to find good tutorials and kick-off projects with some working code. I created jersey2-starter project on GitHub which can be used as starting point for your own production-ready RESTful service. In this post I’d like to cover how to implement and integration test your own validation constraints of REST resources.

Custom constraints

One of the issues which bothers me when coding REST in Java is littering your class model with annotations. Suppose you want to build a simple Todo list REST service, when using Jackson, validation and Spring Data, you can easily end up with this as your entity class:

@Document
public class Todo {
    private Long id;
    @NotNull
    private String description;
    @NotNull
    private Boolean completed;
    @NotNull
    private DateTime dueDate;

    @JsonCreator
    public Todo(@JsonProperty("description") String description, @JsonProperty("dueDate") DateTime dueDate) {
        this.description = description;
        this.dueDate = dueDate;
        this.completed = false;
    }
    // getters and setters
}

Your domain model is now effectively blured by messy annotations almost everywhere. Let’s see what we can do with validation constraints (@NotNulls). Some may say that you could introduce some DTO layer with own validation rules, but it conflicts for me with pure REST API design, which stands that you operate on resources which should map to your domain classes. On the other hand - what does it mean that Todo object is valid? When you create a Todo you should provide a description and due date, but what when you’re updating? You should be able to change any of description, due date (postponing) and completion flag (marking as done) - but you should provide at least one of these as valid modification. So my idea is to introduce custom validation constraints, different ones for creation and modification: 

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForCreation.Validator.class)
public @interface ValidForCreation {
    //...
    class Validator implements ConstraintValidator<ValidForCreation, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && todo.getDescription() != null
                && todo.getDueDate() != null;
        }
    }
}

@Target({TYPE, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = ValidForModification.Validator.class)
public @interface ValidForModification {
    //...
    class Validator implements ConstraintValidator<ValidForModification, Todo> {
    /...
        @Override
        public boolean isValid(Todo todo, ConstraintValidatorContext constraintValidatorContext) {
            return todo != null
                && todo.getId() == null
                && (todo.getDescription() != null || todo.getDueDate() != null || todo.isCompleted() != null);
        }
    }
}

And now you can move validation annotations to the definition of a REST endpoint:

@POST
@Consumes(APPLICATION_JSON)
public Response create(@ValidForCreation Todo todo) {...}

@PUT
@Consumes(APPLICATION_JSON)
public Response update(@ValidForModification Todo todo) {...}

And now you can remove those NotNulls from your model.

Integration testing

There are in general two approaches to integration testing:

  • test is being run on separate JVM than the app, which is deployed on some other integration environment
  • test deploys the application programmatically in the setup block.

Both of these have their pros and cons, but for small enough servoces, I personally prefer the second approach. It’s much easier to setup and you have only one JVM started, which makes debugging really easy. You can use a generic framework like Arquillian for starting your application in a container environment, but I prefer simple solutions and just use emdedded Jetty. To make test setup 100% production equivalent, I’m creating full Jetty’s WebAppContext and have to resolve all runtime dependencies for Jersey auto-discovery to work. This can be simply achieved with Maven resolved from Shrinkwrap - an Arquillian subproject: 

    WebAppContext webAppContext = new WebAppContext();
    webAppContext.setResourceBase("src/main/webapp");
    webAppContext.setContextPath("/");
    File[] mavenLibs = Maven.resolver().loadPomFromFile("pom.xml")
                .importCompileAndRuntimeDependencies()
                .resolve().withTransitivity().asFile();
    for (File file: mavenLibs) {
        webAppContext.getMetaData().addWebInfJar(new FileResource(file.toURI()));
    }
    webAppContext.getMetaData().addContainerResource(new FileResource(new File("./target/classes").toURI()));

    webAppContext.setConfigurations(new Configuration[] {
        new AnnotationConfiguration(),
        new WebXmlConfiguration(),
        new WebInfConfiguration()
    });
    server.setHandler(webAppContext);

(this Stackoverflow thread inspired me a lot here)

Now it’s time for the last part of the post: parametrizing our integration tests. Since we want to test validation constraints, there are many edge paths to check (and make your code coverage close to 100%). Writing one test per each case could be a bad idea. Among the many solutions for JUnit I’m most convinced to the Junit Params by Pragmatists team. It’s really simple and have nice concept of JQuery-like helper for creating providers. Here is my tests code (I’m also using builder pattern here to create various kinds of Todos):

@Test
@Parameters(method = "provideInvalidTodosForCreation")
public void shouldRejectInvalidTodoWhenCreate(Todo todo) {
    Response response = createTarget().request().post(Entity.json(todo));

    assertThat(response.getStatus()).isEqualTo(BAD_REQUEST.getStatusCode());
}

private static Object[] provideInvalidTodosForCreation() {
    return $(
        new TodoBuilder().withDescription("test").build(),
        new TodoBuilder().withDueDate(DateTime.now()).build(),
        new TodoBuilder().withId(123L).build(),
        new TodoBuilder().build()
    );
}

OK, enough of reading, feel free to clone the project and start writing your REST services!