Cloudy with a chance of confusion

Cloud is very popular these day, one of the consequences is the number of terms and products which have the word Cloud in its name which causes a lot of confusion.
I'll try to collect here some of them.

• CloudFormation - AWS Configuration management tool, which uses templates with a special format.
• CloudStack - opensource software to manage VMs.
• CloudFoundry - cloud computing PaaS, some of the cloud providers (e.g. IBM Bluemix) are based on it

Using Java 8 CompletableFuture with Spring @Async annotated methods

Future interface was added in Java 5 but it had a major downside: you had to wait for it to return the result if you wanted to do something with it. Spring framework added SettableListenableFuture which allowed to register callbacks, but now Java 8 added CompletableFuture class and in release 4.2 Spring added support for it.


CompletableFuture allows to chain several asynchronous calls which takes asynchronous to another level. But the class is rather complex, it has more than 40 methods. How do we take advantage of it together with asynchronous support offered by Spring?
 
Lets say we are implementing a method which returns a String result:
 

 public String getResult() {
     return "result";
}

Now we want to make this method asynchronous and return CompletableFuture. Let's assume we already have all the necessary configurations for executing methods with @Async (i.e. we have @EnableAsync annotation in the configuration and defined TaskExecutor bean).

First, we'll add @Async annotation to the method and change the return type.

@Async
public CompletableFuture<String> getResult() {
     return "result";
}

This will not even compile.  But how do we convert string to CompletableFuture? We can use the static method completedFuture:
 

@Async
public CompletableFuture<String> getResult() {
     return CompletableFuture.completedFuture("result");
}

We also need to process the result in the calling method. If we want to process both successes and failures we can execute whenComplete method:

getResult().whenComplete(...);

Now you've taken advantage of CompletableFuture.

Most useful git commands

My favorites are:

git status

This is my favorite git command line command. Right away you can see the branch you are on, all the files that has been changed, the files which are not staged to commit.

git branch -r 

This command shows all remote branches, so you don't have to remember the name of the feature branch which has a 4-digit JIRA story id.


What are yours?

Migrating Spring Rest Service Application to Spring Boot (Part III)

You can read Part I and Part II here and here.

Spring Boot provides a good support for unit and integration testing.  I wanted to take an advantage of that.

First I added dependency for spring-boot-starter-test in my pom.xml,   removed dependencies for jUnit, Mockito and Hamcrest and ran the tests.

Things were not going as smooth as I hoped.

I was using mockMVC which was wired to my WebConfig class (via ContextConfiguration). But that class is no longer needed as Spring Boot takes care of everything. After some digging, adding @SpringApplicationConfiguration(classes = MockApp.class)  worked.

Running unit tests was very useful: it turned out that when removing WebConfig I removed important configuration: useRegisteredSuffixPatternMatch was set to true, which allowed rest requests with domain names in them to be processed correctly and prevented Spring from incorrectly interpreting .com as file extension.

However simply adding this configuration back did not work.  I found several blogs regarding the same issue. In the end the solution was simple, I added back WebConfig which extends WebMvcConfigurerAdapter with overridden configurePathMatch method, but removed @ComponentScan from it.

Cassandra day review

Last week I had an opportunity to attend Cassandra Day in New York. The event took place in Grand Hyatt right by Grand Central.

There were 3 tracks: beginner, advanced and business. I chose the advanced track. It consisted of 8 talks given by Datastax employees as well as developers from other companies who've used Cassandra. All talks were well prepared and interesting. I found the talk about Security the Right Way by Ben Bromhead the most useful. He talked about different aspects of security: authentication, authorization, internode communication as well as security for data at rest. The talk was practical and informative. There are Cassandra Days coming in multiple cities around the world.

By the end of the day the information given became a little bit repetitive: don't do secondary indexes, model to your queries, Spark is good if you want to analyze and aggreagate data,  etc but overall  this is not the bad way to spend the day.

Customizing spring-data-cassandra to support TTL

The REST service I mentioned previously uses Cassandra for data storage and talks to it using Spring Data Cassandra (1.2.2). Integrating with it was easy peasy, all it took is a couple of beans in configuration, and a couple of Repository interfaces (which caused some problems with Spring Boot as I described in this post). But then a new requirement came in, columns in Cassandra had to be inserted with TTL (time to live). CrudRepository methods don't support TTL. In order to support TTL during insertion, save method has to be able to take ttl as a parameter. I wanted to implement this functionality once for all repositories in the application. As described in the documentation,  2 classes needed to be created:

Interface MyRepository, where I added another save method:
Class MyRepositoryImpl, where the method was implemented:

Notice that the documentation is for JPA repositories. For Cassandra repository one more step was needed (I did not find the way around it). Reporsitory Factory Bean needed to be created: and it had to be defined in Configuration: Now we can define a Repository, e.g : Then we just autowire it and call it:

Migrating Spring Rest Service Application to Spring Boot (Part II)

As I mentioned in my previous post, things were not going smoothly. I got a weird java.lang.reflect.InvocationTargetException which was hard to explain. After some Googling I found an explanation.  Turns out the culprit was @Repository annotation in the Repository interfaces which is not needed there. Removing the annotation fixed the issue.

I ran the application and I was able to make REST calls  at localhost:8080/resturl. VICTORY!!!

Wait... Not so fast. I need to add v1/ in front resturl for versioning so the call would be like localhost:8080/v1/resturl .

Hmm. For that I needed to register DispatcherServlet and define the mapping:

I also needed to add a custom filter for Dispatcher Servlet. That was easy: Now I am ready to deploy. But how do I that?