Sunday, May 4, 2014

Managing Spring Boot application

Spring Boot is a brand new application framework from Spring. It allows fabulously quick development and rapid prototyping (even including CLI). One of its main features is to work from single "uber jar" file. By "uber jar" I mean that all dependencies, even an application server like Tomcat or Jetty are packed into a single file. In that we can start web application by typing
java -jar application.jar
The only thing we're missing is the managing script. And now I want to dive into that topic.

Of course to do anything more than starting our application we need to know its PID. Spring Boot has a solution named ApplicationPidListener. To use it we need to tell SpringApplication we want to include this listener. And there are to ways to achieve that.

Thursday, January 23, 2014

Spring Java Config 101

After my last article there were some questions about how Java configuration work in details, and we can extend it to suite our needs. So I'll try to answer those question in this post :)

Heart of Spring java configuration mechanism are @Configuration classes. That's the place where we can define all properties of our Spring context.

Assuming that we lean our application on annotations (which should be true if we want to use java config) we create beans using @Component annotation (with derivatives like @Repository, @Service and @Controller). Varying annotations apply for different layers:

@Componentgeneric for any compoenents
@Repositorypersistence layer
@Serviceservice layer
@Controllerpresentation layer

Saturday, January 18, 2014

Understanding Spring Web Initialization

Few years ago majority of us were used to write XML config files everywhere, to setup even simple Java EE application. Today using Java or Groovy to configure projects is becoming preferred way - you just need to take a look at Gradle or functionalities introduced in further versions of the Spring Framework to gen up on this.

Now I'll deal with configuring Spring contexts for web application.

Java EE provides ServletContainerInitializer interface, which allows libraries to be notified of a web application startup. Since Spring 3.1 we have SpringServletContainerInitializer class which handles WebApplicationInitializer by instantiating all found classes implementing this interface, sorting them basing on @Order annotation (non-annotated classes gets the highest possible order, so they are processed at the end) and invoking onStartup() method.

Saturday, January 11, 2014

Spring integration testing with Spock

I'm currently working on a project where we use Spring Framework 4.0 and Spock for testing. Unit testing in Spock is really great, but there are some lacks in integration testing - especially in mocking Spring beans. Our requirement is to start up Spring context but with particular bean replaced with mock.

The easiest part we had do implement is just regular Spring test specification:

@ContextConfiguration(
        classes = [GatewayConfig, PaymentServiceConfig])
class PaymentServiceSpecIT extends Specification {

  final String CLIENT_ID = "54321"

  @Inject
  PaymentService paymentService

  def "Should return auth token"() {
        when:
            def token = paymentService.getAuthToken(CLIENT_ID)
        then:
            token
    }

}

Friday, September 20, 2013

Injecting Spring beans into non-managed objects

Advantages coming from dependency injection can be addicting. It's a lot easier to configure application structure using injections than doing all resolutions manually. It's hard to resign from it when we have some non-managed classes that are instantiated outside of the container - for example being part of other frameworks like Vaadin UI components or JPA entities. The latter are especially important when we're using Domain Driven Design. During DDD training ran by Slawek Sobotka we were talking about options to remove "bad coupling" from aggregate factories. I'm sure you'll admit, that it's better to have generic mechanism able to "energize" objects by dependencies defined by e.g. @Inject annotation than inject all necessary dependencies into particular factory and then pass them into object by constructor, builder or simple setters.

Spring framework brings us two different solutions to achieve such requirement. I'll now describe them both of them. Let's start with with simpler one.

Sunday, July 14, 2013

Java 7 vs Groovy 2.1 Performance Comparison

I haven't used Groovy for 2 years, since my last touch with Grails. I get stuck in (hard)core Enterprise Java, with some performance aspects in background. I've almost missed a chance to learn Spock, but fortunately Warsaw Java User Group helped me to snap out of some legacy systems and back to normal self-development. In fact I hope that frameworks such as Spock or Geb will change approach to writing tests, by making them easier and more effective. Both frameworks use Groovy, as well as the new king in build tools - Gradle. Seeing pace how Groovy impacts our daily routines I decided to look closer at its performance, and compare it to Java 7.

My test environment is based on Java 1.7.0_25 and Groovy 2.1.6. As always in such comparisons I used Caliper in version 1.0-beta-1 (almost stable) and prepared a number of (I hope) representative microbenchmarks.

First benchmark based on Fork/Join framework should be most similar in both languages, because it uses some native mechanisms. My test initialize array with some random int data, and then use framework to find biggest element in array. In Groovy my compute functions looks like below:
@Override
Integer compute() {
  def size = end - start
  if (size == 1) {
    Math.max(array[start], array[end])
  } else {
    int diff = size / 2
    MaxValueSeeker left = 
      new MaxValueSeeker(array, start, start + diff)
    left.fork()
    MaxValueSeeker right = 
      new MaxValueSeeker(array, start + diff, end)
    Math.max(right.compute(), left.join())
  }
}
Java version is of course very similar. After dozen minutes of measuring I get very promising result: Groovy is slower only... 8 times :)

Saturday, July 13, 2013

Confitura 2013 - first time on the other side

I used to attend Confitura (formerly Javarsovia) or at least watch videos from presentations. I even had a chance to speak on it 4 years ago and share my reflections about continuous integration. This year I also decided to try to organize myself and prepare presentation about profiling Java Virtual Machine. Few days after submitting abstract, my chat window blinks with Tomek Dziurko saying:
 - "Hello! Confitura Organisation Commitee would like to invite you to join us. We don't give anything in return except satisfaction, but we take a lot of time. Are you in?"
Of course it's great honor but also we've to remember that with great power comes great responsibility :) Finally after exchanging a few words I've decided to accept challenge and put my shoulder to the wheel! Now I can say that it was definitely great decision! Guys - if you're reading this post please know, that working with you is a huge delight!

But I'm not going to sum up months of preparations and thousands of emails right now - I just want to share my feedback about conference.

Saturday, 6th July started for me at 6am, when I arrived at Warsaw University campus. We made finishing touch, provide some help for sponsors working on theirs booths and about eight o'clock first attendees appeared. Volunteers did really great job unloading registration queues (and also in many different things, helping us through whole conference). We've no more to do except get our aprons on, take big pot full of prizes and go straight for biggest lecture hall to open today's event! It was really, really nice to see so many geeks spending theirs free time to develop skills and help us making Confitura so unique conference!