Skip to content

Don't Panic! Posts

Docker Part 1: Running Containers

Docker is a containerization technology that’s been getting quite a bit of attention over the last year or two. It offers a more lightweight, flexible and repeatable alternative to creating and running full Virtual Machines (VMs). In this, the first in a series of posts on Docker, I’ll look at how to run an application inside of a pre-built container image. In this series, I’ll look at:

  1. Running Containers (this post);
  2. Building Images: How to create a new container image, customized to your requirements;
  3. Disposable Containers: Using containers to run a short-lived job rather than a long-lived service;
  4. Composing an Environment Stack: Creating an environment composed of multiple linked containers.

User Impersonation with Spring Security SwitchUserFilter

A common requirement for secured applications is that admin / super users are able to login as any other user. For example, it may be helpful for a customer support analyst to access a system as if they were a real specific customer. The obvious way to do this is for the admin user to ask for the customer’s password or look it up in the password database. This is usually an unacceptable security compromise – no one should know a customer’s password except for the customer. And if the password database is implemented correctly it should be technically impossible for anyone – not even a system admin or DBA – to discover a user’s password.

An alternative solution is to allow admin users to login with their own unique username and password but allow them to then impersonate any other user. After the admin user has logged in, they can enter the username of another user and then view the application as if they were logged in as that user. Implementing user impersonation in this way also has the advantage that the system knows who has really logged in. If the system has an audit log, we can audit actions against the real admin user, rather than the impersonated user.

Building Unit Test Data

Unit tests have most value when they’re easy to read and understand. Unit tests typically follow a very straightforward pattern:

  1. Simulate system state
  2. Call the method under test
  3. Verify the method’s result and side effects

So long as this pattern is obvious in the test, the test is readable.

Deploying to Tomcat 7 with Maven

The Tomcat7 plugin for Maven has a number of uses. In a previous post, I’ve looked at using it to deploy a build to an embedded Tomcat server for integration testing with Selenium.

A more simple use case is to simply deploy (or undeploy) a built artifact (war) to a Tomcat installation on a local machine or on a remote server.

The following examples are available to download from the Spanners Demo on GitHub.

Testing for SimpleDateFormat thread safety

It’s a little alarming how many good developers are unaware that many standard Java classes – including subclasses of Format – are not thread safe. Many are also not sure about how their applications perform in a multi-threaded environment or how their web application container (Tomcat) will run their app in multiple threads. This can cause nasty intermittent bugs that can be incredibly hard to find and fix. It’s important to be aware of threading issues at development time but it’s also important to be able to test for them.