Using Spring Boot Devtools with LiveReload

The (very) short introduction

Using the Spring Boot Devtools can help to increase your development speed. Simply put the corresponding Spring Boot Starter into your application’s dependency tree and voilà—restart, reload, development-optimised settings, … (obviously I’m still in the “wow-that-is-sooooo-amazing”-phase and haven’t had any issues with the devtools so far. Which explains my enthusiasm.).

Nonetheless, including the Spring Boot Devtools in your application will also start a LiveReload-Server:

The spring-boot-devtools module includes an embedded LiveReload server that can be used to trigger a browser refresh when a resource is changed. LiveReload browser extensions are freely available for Chrome, Firefox and Safari from livereload.com.

(Taken from https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-devtools-livereload

And that’s where the fun begins: most of the plugins are outdated; don’t connect to a LiveReload-Server, but rather simply refreshe the current tab in a given interval; or aren’t that popular (in downloads/likes/whatever) that I would want them to be running in my browser.

But there is another solution: a little JavaScript (livereload-js) which could be included in your HTML. This little script connects to a LiveReload-Server and reloads the current page whenever the server tells it to.

Read more

a mac and glasses

A Less Mixin for JSF 2 Resource Handling

JSF 2.0 introduced it’s own resource handling. One of the disadvantages of this solution is, that referring to an images inside your CSS doesn’t work the common way:

.foo {
    background-image: url('images/logo.gif'); // doesn't work with JSF 2.x
}

You need to use expression language like:

.foo {
    background-image: url("#{resource['images/logo.gif']}");
}

Now if you are using LESS and don’t want to write this expression over and over again—you need a mixin:

.background-image(@filename) {
    background-image: e(%("url(#{resource['images:%s']})", @filename));
}
public class FooService {

    // TODO: remove me!
    // public final static String NOT_YET = "";

    ...
}

(Taken from production code)

clock

Timeout Configuration in HikariCP, DB2 and MySQL

Motivation

Michael T. Nygard warns in “Release it” [1] about the lack of timeouts caused by misconfigured database drivers and connection pools. He argues that if a connection pool gets exhausted when none of its calls return than all others threads get blocked as soon as they require a connection too. His advice is:

Scrutinize Resource Pools
Safe resource pools always limit the time a thread can wait to check out a resource.
(Michael T. Nygard, “Release it”, P. 50)

So I wondered, whether the connection pool HikariCP as well as the JDBC-driver of IBM DB2 and MySQL already ships with default timeouts (and how to adjust them).

Read more