The new version IntelliJ IDEA 2016.2 is out!
It includes a new feature to support font ligatures.
It looks very promising, so I downloaded and installed the font FiraCode.
But I noticed rough edges in the font.
I enabled the feature in Settings → Editor → Colors & Fonts → Font and selected FiraCode as Font.
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.
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:
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 Grails Goodness: Creating A Fully Executable Jar.
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:
org.springframework.boot
spring-boot-maven-plugin
true
## Gradle configuration
```gradle
apply plugin: 'spring-boot'
springBoot {
executable = true
}
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.
An example of an .editorconfig file looks like:
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.
package com.jdriven.example;
import org.springframework.context.annotation.Configuration;
@Configuration
public class MyOwnAutoConfiguration {
//You can define your own beans here and
//further setup this Configuration as you normally would do
}
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:
@RestController
public class MyController {
@RequestMapping("/persons")
//I want the version to be automatically injected
public List getPersons(String version) {
.....
return someList;
}
}
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.
As a Spring developer we know how to load a resource in a Service. The prefixes of classpath: and file: are commonly used. But what if we want to load resources from a different location like a database table RESOURCE, with our own prefix db:? The Spring Framework provides some default built-in resource implementations, which can be found in the chapter Resources in the Spring Framework Reference Guide. The URL is prefixed and handled by the corresponding ResourceLoader (JavaDoc). If we want to load a resource from a database table RESOURCE we have to create our own ResourceLoader which triggers on the prefix db:.
Let's create an interface which describes the action of getting a resource based on the resourceName.
When we a have Spring managed application, we want to let Spring manage all of our beans. Beside the regular way of creating beans with known solutions like Annotated beans, Java Configuration and XML Configuration, there is also a way in which we can create our own BeanDefinition. With a BeanDefinitionRegistryPostProcessor it is possible to create a specific post processor which can add BeanDefinitions to the BeanDefinitionRegistry. It differs from the BeanPostProcessor, which only has hooks for Bean Initialization (construction of your POJO), where the BeanDefinitionRegistryPostProcessor has a hook on the BeanDefinitionRegistry. This gives us the ability to define our own BeanDefinition. First we create a BeanDefinitionRegistryPostProcessor implementation as listed in the example. We implement the required method, and will be able to add our own bean definition to the registry. The defined BeanDefinition will be picked up by the ApplicationContext and the POJO will be constructed. Our result is A Spring managed bean
package com.jdriven;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.stereotype.Component;
@Component
public class LogicServiceRegistryPostProcessor
implements BeanDefinitionRegistryPostProcessor {
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
throws BeansException {
RootBeanDefinition beanDefinition =
new RootBeanDefinition(MyServiceImpl.class); //The service implementation
serviceDefinition.setTargetType(MyService.class); //The service interface
serviceDefinition.setRole(BeanDefinition.ROLE_APPLICATION);
registry.registerBeanDefinition("myBeanName", beanDefinition );
}
}
When we construct an typed Array out of an existing List, we use the method T[] toArray(T[] a). When an array with a lower size than the size of the List is passed as argument, this results in a new array being created. Take a look at the implementation of ArrayList here. Using the method with an incorrect sized array is inefficient. Using the toArray method directly with a correctly sized array is therefore preferable.
ArrayList myList; //Assume myList has some added entries
//Size is too small a 2nd array will be created
MyClass[] arr = myList.toArray(new MyClass[0]);
I would like to show different ways of using Spring's @Autowired annotation: Constructor, Method and Field autowiring.
The examples I show are all a form of byType autowiring mode (constructor autowiring mode is Analogous to byType). Take a look at the Spring Reference guide for more information on the Autowiring modes.
Create a constructor with a dependent bean as constructor parameter and add the @Autowired annotation to the constructor. A big advantage of autowiring by constructor is that the field can be made final, and therefore may not be changed after construction.
As shown in a the post Nifty JUnit : Working with temporary files, it is possible to use @Rule in a JUnit test, which is a Method level Rule. In this example I would like to show the variation of the @ClassRule for a Class level Rule.
The @Rule is fired before each test method (just like @Before) and after each test method (just like @After) of the test class, as shown in the example below.
