Surprising and dangerous Spring shutdown behaviour
Just by chance I noticed that one of my beans were being closed twice when the Spring context was closed down. It turns out that Spring is, by default actively looking for some way to close down all beans during shutdown. It’ll actually fall back to invoking a method called “close” if nothing else has been configured!
While this might sound like a feature and even a good idea, I don’t trust Spring to figure out a safe order to close down thread pools, executors, clients and other resources with a life cycle! It’s probably not a good idea to close down the database connection before the executor service that’s currently processing remaining tasks from a queue..
package com.developerb.spring;
import org.junit.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import static junit.framework.TestCase.assertFalse;
/**
* Unit test demonstrating surprising and dangerous behaviour
* when shutting down a Spring Application Context. It turns out
* that Spring will, by default invoke a method named "close"
* during shutdown.
*
* @author Kim A. Betti <kim@developer-b.com>
*/
public class BugOfDestructionTest {
@Test
public void experimental() {
AnnotationConfigApplicationContext context = createContext();
RandomClient client = getClientFromContext(context);
context.close();
// This should not happen!!
assertThatTheCloseMethodHasNotBeenInvoked(client);
}
private AnnotationConfigApplicationContext createContext() {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
context.register(TestConfiguration.class);
context.refresh();
return context;
}
private RandomClient getClientFromContext(AnnotationConfigApplicationContext context) {
RandomClient client = context.getBean(RandomClient.class);
assertThatTheCloseMethodHasNotBeenInvoked(client);
return client;
}
private void assertThatTheCloseMethodHasNotBeenInvoked(RandomClient client) {
assertFalse("Spring has invoked the close method!", client.hasBeenClosed);
}
@Configuration
static class TestConfiguration {
@Bean
RandomClient client() {
return new RandomClient();
}
}
static class RandomClient {
public boolean hasBeenClosed = false;
public void close() {
hasBeenClosed = true;
}
}
}
This problem seems to be originating in Spring’s DisposableBeanAdapter.
Google Apps Script - Forward travel confirmations to TripIt for indexing
Tripit can be configured to automatically browse through all your email looking for travel information. Although I really like their product, I’m not really comfortable letting them dive into my personal email. So for some time I’ve been manually forwarding them all travel confirmations for indexing.
Some time ago a friend of mine told me about Google Apps Script. I have to say that I’m very, very impressed with what Google has pulled of here! From knowing nothing at all to having working code that automated my previously manual GMail workflow just took me an hour!
function processTripItQueue() {
var archiveLabel = GmailApp.getUserLabelByName("Personlig/Reise");
var queueLabel = GmailApp.getUserLabelByName("tripit-queue");
var threads = queueLabel.getThreads();
for (var i = 0; i < threads.length; i++) {
var tripThread = threads[i];
var messages = tripThread.getMessages();
for (var j = 0; j < messages.length; j++) {
var queuedMessage = messages[j];
Logger.log('Forwarding "%s" to plans@tripit.com', queuedMessage.getSubject());
queuedMessage.forward("plans@tripit.com");
}
queueLabel.removeFromThread(tripThread);
archiveLabel.addToThread(tripThread)
}
}
function onInstall() {
var everySixHours = ScriptApp.newTrigger('processTripItQueue')
.timeBased()
.everyHours(6)
.create();
}
Pretty cool!
Being The Worst
I’m very much enjoying this podcast about cqrs, event sourcing, domain driven design and distributed systems in general!
JUnit @Rule for integration testing Dropwizard applications
Shutting down Dropwizard programmatically turned out to be a bit tricky due to the way it’s started. This in turn made it difficult to start and stop instances for integration testing without forking multiple JVM instances.
Working around it turned out to be fairly straight forward though. Here is the result implemented as a JUnit rule. The test server will take care of starting and stopping a Dropwizard service around each test without forcing inheritance upon the test class.
Vertx weekend experiment - Real time Dropwizard dashboard
This was just a weekend experiment to refresh my Javascript knowledge and try out some technologies I’ve been looking at for some time. Don’t expect it to be of production quality or that I’ll maintain it.
Dropwizard is a well instrumented and productive framework for building production ready restful web services. It exports a lot of statistics on a admin port. I thought it would be fun to create a proxy polling this endpoint and feeding the data to clients connected via web sockets. The proxy is implemented using the fairly new Vertx framework enabling highly concurrent polygot application development on the JVM.
While I was working on the client side of the dashboard I thought it would be fun to have a look at Knockout.js for data binding. I quite liked the declarative way it solves a lot of common problems related to data binding.
I’m giving Vertx a spin and as the examples demonstrates how to boot a Vertx application from the command line I was curious about how to start it from Intellij IDEA to gain debugging support. Turned out to be pretty simple.
Dropwizard - Instrumentation of Guice beans annotated with @Timed
With wife and baby visiting grand parents this weekend I’ve had some time to look into Dropwizard. Dropwizard is a pretty productive framework for exposing restful web services.
It comes with awesome instrumentation capabilities out of the box, but only for Jersey resources, but it turns out to be ridiculously simple to add this capability to other beans by adding Google’s Guice to the mix.
Relevant code at Github: https://gist.github.com/2623833
Ps! The same could thing could be accomplished with Spring using BeanPostProcessor or its AOP support.
Don’t run Maven with -DskipTests=true and expect it to generate a test-jar!
It is not so much that I have confidence in scientists being right, but that I have so much in nonscientists being wrong.

