Spring Boot and Scala with sbt as the build tool

Earlier I had blogged about using Scala with Spring Boot and how the combination just works. There was one issue with the previous approach though - the only way to run the earlier configuration was to build the project into a jar file and run the jar file.

./gradlew build
java -jar build/libs/spring-boot-scala-web-0.1.0.jar

Spring boot comes with a gradle based plugin which should have allowed the project to run with a "gradle bootRun" command, this unfortunately gives an error for scala based projects.

EDIT: This is actually not completely true, another way to run the Spring-boot code using gradle will be to use the gradle application plugin and specify the main program this way:

apply plugin:'application'
mainClassName = "mvctest.SampleWebApplication"

A good workaround is to use sbt for building and running Spring-boot based projects. The catch though is that with gradle and maven, the versions of the dependencies would have been managed through a parent pom, now these have to be explicitly specified. This is how a sample sbt build file with the dependencies spelled out looks:

name := "spring-boot-scala-web"

version := "1.0"

scalaVersion := "2.10.4"

sbtVersion := "0.13.1"

seq(webSettings : _*)

libraryDependencies ++= Seq(
  "org.springframework.boot" % "spring-boot-starter-web" % "1.0.2.RELEASE",
  "org.springframework.boot" % "spring-boot-starter-data-jpa" % "1.0.2.RELEASE",
  "org.webjars" % "bootstrap" % "3.1.1",
  "org.webjars" % "jquery" % "2.1.0-2",
  "org.thymeleaf" % "thymeleaf-spring4" % "2.1.2.RELEASE",
  "org.hibernate" % "hibernate-validator" % "5.0.2.Final",
  "nz.net.ultraq.thymeleaf" % "thymeleaf-layout-dialect" % "1.2.1",
  "org.hsqldb" % "hsqldb" % "2.3.1",
  "org.springframework.boot" % "spring-boot-starter-tomcat" % "1.0.2.RELEASE" % "provided",
  "javax.servlet" % "javax.servlet-api" % "3.0.1" % "provided"
)


libraryDependencies ++= Seq(
  "org.apache.tomcat.embed" % "tomcat-embed-core"         % "7.0.53" % "container",
  "org.apache.tomcat.embed" % "tomcat-embed-logging-juli" % "7.0.53" % "container",
  "org.apache.tomcat.embed" % "tomcat-embed-jasper"       % "7.0.53" % "container"
)

Here I am also using xsbt-web-plugin which is plugin for building scala web applications.

xsbt-web-plugin also comes with commands to start-up tomcat or jetty based containers and run the applications within these containers, however I had difficulty in getting these to work.

What worked is the runMain command to start up the Spring-boot main program through sbt:

runMain mvctest.SampleWebApplication

and xsbt-web-plugin allows the project to be packaged as a war file using the "package" command, this war deploys and runs without any issues in a standalone tomcat container.

Here is a github project with these changes: https://github.com/bijukunjummen/spring-boot-scala-web.git

Using Http Session with Spring based web applications

There are multiple ways to get hold of and use an Http session with a Spring based web application. This is a summarization based on an experience with a recent project.

Approach 1

Just inject in HttpSession where it is required.

@Service
public class ShoppingCartService {
 
 @Autowired 
 private HttpSession httpSession;
 
 ...
} 

Though surprising, since the service above is a singleton, this works well. Spring intelligently injects in a proxy to the actual HttpSession and this proxy knows how to internally delegate to the right session for the request.

The catch with handling session this way though is that the object being retrieved and saved back in the session will have to be managed by the user:

public void removeFromCart(long productId) {
 ShoppingCart shoppingCart = getShoppingCartInSession();
 shoppingCart.removeItemFromCart(productId);
 updateCartInSession(shoppingCart);
}

Approach 2

Accept it as a parameter, this will work only in the web tier though:

@Controller
public class ShoppingCartController {

  @RequestMapping("/addToCart")
  public String addToCart(long productId, HttpSession httpSession) {
    //do something with the httpSession 
  }

}

Approach 3
Create a bean and scope it to the session this way:

@Component
@Scope(proxyMode=ScopedProxyMode.TARGET_CLASS, value="session")
public class ShoppingCart implements Serializable{
...
}

Spring creates a proxy for a session scoped bean and makes the proxy available to services which inject in this bean. An advantage of using this approach is that any state changes on this bean are handled by Spring, it would take care of retrieving this bean from the session and propagating any changes to the bean back to the session. Further if the bean were to have any Spring lifecycle methods(say @PostConstruct or @PreDestroy annotated methods), they would get called appropriately.

Approach 4
Annotating Spring MVC model attributes with @SessionAttribute annotation:

@SessionAttributes("shoppingCart")
public class OrderFlowController {
 
 
 public String step1(@ModelAttribute("shoppingCart") ShoppingCart shoppingCart) {
  
 }
 
 public String step2(@ModelAttribute("shoppingCart") ShoppingCart shoppingCart) {
  
 }
 
 public String step3(@ModelAttribute("shoppingCart") ShoppingCart shoppingCart, SessionStatus status) {
  status.setComplete();
 } 

}

The use case for using SessionAttributes annotation is very specific, to hold state during a flow like above


Given these approaches, I personally prefer Approach 3 of using session scoped beans, this way depending on Spring to manage the underlying details of retrieving and storing the object into session. Other approaches have value though based on the scenario that you may be faced with, ranging from requiring more control over raw Http Sessions to needing to handle temporary state like in Approach 4 above.

Spring test with thymeleaf for views

I am a recent convert to thymeleaf for view templating in Spring based web applications, preferring it over jsp's. All the arguments that thymeleaf documentation makes on why thymeleaf over jsp holds water and I am definitely sold.

One of the big reasons for me, apart from being able to preview the template, is the way the view is rendered at runtime. Whereas the application stack has to defer the rendering of jsp to the servlet container, it has full control over the rendering of thymeleaf templates. To clarify this a little more, with jsp as the view technology an application only returns the location of the jsp and it is upto the servlet container to render the jsp.

So why again is this a big reason - because using the mvc test support in spring-test module, now the actual rendered content can be asserted on rather than just the name of the view.

Consider a sample Spring MVC controller :

@Controller
@RequestMapping("/shop")
public class ShopController {
    ...
     
 @RequestMapping("/products")
 public String listProducts(Model model) {
  model.addAttribute("products", this.productRepository.findAll());
  return "products/list";
 }
} 

Had the view been jsp based, I would have had a test which looks like this:

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration(classes = SampleWebApplication.class)
public class ShopControllerWebTests {

 @Autowired
 private WebApplicationContext wac;

 private MockMvc mockMvc;

 @Before
 public void setup() {
  this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).build();
 }

 @Test
 public void testListProducts() throws Exception {
  this.mockMvc.perform(get("/shop/products"))
   .andExpect(status().isOk())
   .andExpect(view().name("products/list"));
 }
}

the assertion is only on the name of the view.

Now, consider a test with thymeleaf used as the view technology:

@Test
public void testListProducts() throws Exception {
 this.mockMvc.perform(get("/shop/products"))
  .andExpect(status().isOk())
  .andExpect(content().string(containsString("Dummy Book1")));
}

Here, I am asserting on the actual rendered content.

This is really good, whereas with jsp I would had to validate that the jsp is rendered correctly at runtime with a real container, with thymeleaf I can validate that rendering is clean purely using tests.

Memoization of Scala Streams

I learnt the hard way that scala internally uses memoization with Streams.

This was my first attempt at a solution to Euler Problem 5

def from(n: Int): Stream[Int] = n #:: from(n + 1)

def isDivisibleByRange(n: Int, r: Range) = {
  r.forall(n % _ == 0)
}

val a = from(21)
val o = a.find(isDivisibleByRange(_, Range(2, 21)))
o match {
  case Some(i) => println(i)
  case None => println("Nothing found!")
}

I was a little mystified by why this code was throwing an OutOfMemoryError, realized thanks to Stackoverflow that since the answer to this problem is quite high 232792560, all the integers in this range will be memoized within the different nodes of the stream and hence the issue.

This is actually easy to see, let me first modify the stream generator function with a side effect:

def from(n: Int): Stream[Int] = {println(s"Gen $n"); n #:: from(n + 1)}
val s = from(1)
s.take(10).toList 
s.take(10).toList

The second statement would not print anything.

Given this memoization behavior there are a few possible fixes, the simplest is to not keep a reference to the head of the stream anywhere and to use the find method of iterator instead:

from(1).iterator.find(isDivisibleByRange(_, Range(1, 21)))

On a related note, Java 8 streams are not memoized and a solution using Java 8 streams (admittedly can be improved massively) is the following:

@Test
public void testStreamOfInts() {
 Stream<Integer> intStream = Stream.generate(from(1));
 List<Integer> upto20 = IntStream.rangeClosed(1, 20).boxed().collect(Collectors.toList());
 Predicate<Integer> p = (i -> isDivisibleOverRange(i, upto20));
 Optional<Integer> o = intStream.filter(p).findFirst();
 o.ifPresent(i -> System.out.println("Found: " + i));
}

private Supplier<Integer> from(Integer i) {
 AtomicInteger counter = new AtomicInteger(0);
 return () ->  counter.incrementAndGet();
}

private boolean isDivisibleOverRange(Integer n, List<Integer> l) {
 return l.stream().allMatch(i -> n % i == 0);
}