Spring Batch and Feign OAuth2 RequestInterceptor

We have a microservice architecture with one of the microservices having a Spring Batch job which processes a CSV file and calling another microservice. Both microservices are OAuth2 protected ResourceServers. When we call the first microservice, a batch job is started and we want the Authorization header to be passed to the second microservice. The solution can be defined as:

In a Feign RequestInterceptor, grab the current OAuth access_token and pass it on the the RequestTemplate with Hystrix running in SEMAPHORE execution isolation strategy

Define Job execution

RequestInterceptor

Hystrix isolation strategy

Now we set the default isolation strategy of hystrix to SEMAPHORE. Otherwise we will get an error:
Method threw 'org.springframework.beans.factory.BeanCreationException' exception.... Scope 'session' is not active for the current thread;

Spicy Spring: Customize error JSON response with ErrorAttributes

The default JSON error body of Spring Boot can be customized or extended by defining our own ErrorAttributes implementation. In Spring Boot we get an error response JSON format for free. Any thrown Exception is automatically translated to this JSON format and returned with a corresponding HTTP status.

Default implementation

As soon as we throw an Exception in a @RequestMapping annotated method of a @Controller, the thrown Exception is translated to a HTTP status and a JSON error body.

The default JSON error body looks like:

Write your own ErrorAttributes implementation

What if we want extra attributes in this JSON error body?

Just define an implementation for ErrorAttributes and register it as a Spring @Component. The following example will result in a customized JSON error response body with the cause of the exception included.

Our resulting body will now look like:

Happy developing!

Spicy Spring: Creating a Fully Executable Jar

With a Spring (Boot/Cloud) application you can create a fully executable JAR, where the jar can be run from the command-line by just calling ./my-own-jar-0.0.1.jar.
My colleague Mr. Haki wrote a nice blog about creating a fully executable JAR for Grails.

Together with the famous one-liner of Josh Long in mind: “Make JAR not WAR!”, create a JAR whenever you develop a Spring Boot/Cloud application. As described in Mr. Haki’s blog, it is very easy to make our Spring application executable:

Maven configuration

Gradle configuration

You can find the description in the Spring Reference guide.

Happy Developing! And remember, “Make JAR not WAR!”

Generic Code Formatting with EditorConfig example

I love code. I take care of my code and I like my code to be formatted nicely. No matter if I’m on Eclipse, Netbeans or IntelliJ, I want my code to be formatted the same.

Nowadays we have EditorConfig. In the source code we can place a file .editorconfig with formatting instructions. These instructions can be read by many Tools like Eclipse, Netbeans, IntelliJ and VisualStudio. If we create an .editorconfig file with formatting instructions, these rules are automatically applied.

Example

An example of an .editorconfig file looks like:

As you see you can define specific formatting rules for different file types.

Happy coding and formatting!

Spicy Spring: Write your own AutoConfiguration

In Spring we use the @EnableAutoConfiguration each time when we use the @SpringBootApplication annotation. If we look at the @SpringBootApplication we can see that this automatically enables the @EnableAutoConfiguration. This last mentioned annotation triggers all the auto-configuration enabled configurations on the classpath. We can write an auto-configuration enabled @Configuration ourself in only two steps.

In /src/main/resources/META-INF/ create a file called spring.factories and add the following snippet to the file.

If you wrap this all in a JAR and add this as a classpath dependency to another Spring Application, the above MyOwnAutoConfiguration is triggered.

Happy developing!

Spicy Spring: Inject your custom method argument in Spring MVC using HandlerMethodArgumentResolver

In Spring MVC we get some method argument types resolved by default and injected in Spring MVC controller methods. Some examples are Model, Locale and OutputStream.
What if we want to inject a custom argument in Spring MVC controller methods? In this example we extract the X-Application-Version HTTP header from the request and inject that as a method argument called version.

Our controller class will look like the following:

This is where we need to write our own HandlerMethodArgumentResolver implementation which is responsible for extracting the X-Application-Version from the HttpHeader.

Continue reading

Building your own self refreshing cache in Java EE

If you have read my previous post about caching, The (non)sense of caching, and have not been discouraged by it, I invite you to build your own cache. In this post we will build a simple cache implementation that refreshes its data automatically, using Java EE features.

Context: A slow resource

Let’s describe the situation. We are building a service that uses an external resource with some reference data. The data is not frequently updated and it’s allright to use data that’s up to 1 hour old. The external resource is very slow, retrieving the data takes about 30 seconds.

Our service needs to respond within 2 seconds. Obviously we can’t call the resource each time we need it. To solve our problem we decide to introduce some caching. We are going to retrieve the entire dataset, keep it in memory and allow retrieval of specific cached values by their corresponding keys.

Step 1: Getting started

A very basic implementation of a key-value cache is a (java.util.)Map, so that’s where we’ll start. One step at a time we will extend this implementation untill we have a fully functional cache.

Step 2: Populating the cache

We will inject a bean that serves as a facade to our slow external resource. To keep things simple in this example, the bean returns a list of SomeData objects that contain a key and a value.

Step 3: Keeping state between requests

Now we can populate the cache we need to keep the state so that future requests can also make use of it. That’s where we use the Singleton bean. A singleton session bean is instantiated once per application and exists for the lifecycle of the application, see also the JEE tutorial page about Session Beans.

Note that, when we run our application in a clustered environment, each instance of our application will have its own Singleton bean instance.

Note that, when we run our application in a clustered environment, each instance of our application will have its own Singleton bean instance.

Step 4: Populating the cache before first use

We can use the @PostConstruct annotation to fill the cache with the reference data when the bean is created. If we want the cache to load at application startup instead of on first access, we use the @Startup annotation.

Step 5: Accessing the cached data

To make the data available, we create a public method getData, that will retrieve the cached value by its key.

Step 6: Refreshing the cache periodically

As the cached data becomes outdated over time, we want to refresh the het dataset automatically after a specified time period. JEE offers a solution with automatic timers. See also the JEE tutorial page about the Timer Service. We configure the timer to be not persistent.

Step 7: Manage concurrency

Finally, we need to make sure concurrency is handled correctly. In JEE, you can do this either Container-Managed or Bean-Managed. For Singleton Session Beans the default is Container-Managed Concurrrency with a Write Lock on each public method. Whenever the bean is called, all subsequent calls will be held until the lock is released. This is safe, even if you are modifying the data, hence the name Write Lock.

We can improve on this by allowing concurrent read acces on methods that are only reading data, in our case the getData method. To do that we add the @Lock(LockType.READ) annotation. This way, calls to the getData method are only held when a method with a Write Lock is being accessed.

(In our simple case we could get away without any locking at all because updating the object reference of our instance variable cache in the populateCache method is an atomic operation, but in practice you don’t want to depend on implementation details of the populateCache method.)

For more information about Container-Managed Concurrency check the JEE tutorial page about Managing Concurrent Access.

Practical use

Above example code is perfeclty usable, but there are several things to consider:

  • In the example we load the entire dataset into memory. This is only feasable if the dataset is not too big, e.g. a list of Currency Conversion Rates.
  • When you deploy on multiple servers, each of them will have its own cache. Because they will each be refreshing independently, they might not hold the exact same dataset. This might confuse the users of your application.

Conclusion

We have created a simple cache with a minimal amount of code. By making use of built-in Java EE features, a lot of complex tasks are managed by the JEE container, making our job easier.

Javaland 2016 Conference Report

It has already been a week since Javaland 2016 started on Tuesday March 8th. Javaland is 3-day community driven conference in the amusement park Phantasialand in Brühl, Germany. I had the fortune to attend the conference this year and speak about Asciidoctor on the first day with my talk “Writing documentation in Asciidoctor is Awesome”. The code and examples from the presentation are on Github. Also my colleague Rob Brinkman was at the conference for this talk about “Westy Tracking (turning a VW van into a Tesla)” and his presentation is online as well.

What I really liked about the conference is a lot of technical talks about all kind of Java subjects. Even for a non-German person there were a lot of talks in English to follow. Also the atmosphere was very nice, people are approachable and in between talks there was a nice community and sponsor exhibition room. The organization uses the knowledge and experience of 29 JUGs from Germany, Austria and Switzerland. And then the location is also great to have a conference. The amusement park wasn’t open for the public so we as Java developers had part of the park for ourselves. The location of the talks were partially in theaters and in business rooms. And at Tuesday night we were allowed to go on rides as well. (Remember: first rides, then eat and drink, if you alter the order you might get in trouble).

The first day started with an explanation about the program, talks, different community events from the organization. Next we attended a session about how to visualize relations between Wikipedia articles from James Weaver. He showed a Spring application backend with an Angular frontend running on Cloudfoundry. Next up was Rob Brinkman with his excellent talk on how he added electronics to an “old” VW van, so he could save his trips and tracking information. He showed the software architecture he used with Vert.x 3, Redis, Java 8 and Angular to make it all work together. It was time for lunch and that was very good organized. A lot of different things to choose from and it tasted very well. After lunch we attended a short talk about streams and reactive programming that was very informative given by Jan Carsten Lohmüller. In the afternoon we stayed a while at the community floor and stumbled upon a nice small presentation from Andres Almiray about a JSR for desktop applications. The setting was very informative and I really liked this aspect of the conference. Furthermore we attended a session about Lombok to reduce the boilerplate code in Java presented by Roel Spilker and Reinier Zwitserloot. Bert Jan Schrijver gave a good presentation about performance testing with Gatling. He even did live Scala coding on stage! Gatling looks like a very nice tool to define scenario’s for simulating multiple users accessing your application.

At night the park was open and some attractions were open, especially the roller coaster rides. Also there was a good diner organized at different locations.

The second day of the conference started for me with a talk by Josh Long about Spring Cloud. The Spring Cloud project has a lot of very useful subprojects to work with microservices in a distributed manner. Even though the session could only last 40 minutes Josh managed to show a lot of cool stuff with live coding small applications. At lunch time I attended a good talk which started with a cool Lego demo by Johan Janssen and Martin Kanters. They managed to control Lego trains and a fairy wheel from their browser. And it all worked as well. They used Akka on Raspberry Pi’s to make it all work and explained the software architecture.

After another tasteful lunch I learned more about monads in Java 8. Normally this is a very theoretical subject, but presenter Oleg Shelajev did a good job and showed real code on how monads appear in Java. The last session of the day was about using Groovy as a system scripting language by Andrey Adamovich. He showed the cool stuff of Groovy to make as script developer so much easier. Instead of relying on Bash or another script language, just use Groovy and all the Java libaries we already know.

The final day of the conference was a tutorial/workshop day. I attended a Vert.x 3 workshop given by Jochen Mader. Although it was in German I could still follow it very well. He presented some theory and then we could make small exercises in Vert.x 3. Then we would look at possible solutions for the exercise given by Jochen. I learned a lot during this day.

It was the first time I went to Javaland and it was a very good experience. The location, the organization and the content are all excellent. Although I already know I cannot make it next year, I still want to come back during the next years.

Original blog post

Use Spring classpath Resource as Tuckey UrlRewriteFilter configuration

Use Spring classpath Resource as Tuckey UrlRewriteFilter configuration

Recently I wanted to use the Tuckey UrlRewriteFilter.
It is described as: A Java Web Filter for any compliant web application server, which allows you to rewrite URLs before they get to your code.

I wanted to load my urlrewrite.xml as a Spring (classpath) resource, instead of loading it from the default location provided by the UrlRewriteFilter. The default behavior loads the configuration file from /WEB-INF/ulrewrite.xml. In my case I wanted to load it from the /src/main/resources folder, which is the root of my classpath.

With this small and easy to use decorated UrlRewriteFilter, you can load your configuration from any location. When you write a UnitTest for this decorated Filter, don’t forget to call the init() method before you call the actual doFilter(). For testing your UrlRewriteFilter rules, it is better to write an IntegrationTest, for example with the TestRestTemplate