Google App Engine makes it easy to deploy NodeJS applications. The GAE Standard Environment and SDK support NodeJS out of the box. This makes Google App Engine a great choice ahead of competitors such as Heroku, AWS or Microsoft Azure. Unfortunately though, there’s no support for managing secrets in Google App Engine. When I deployed Dog n Bone to GAE, I found this single shortcoming the main source of complexity.
There are however some workarounds. None of them is particularly nice though.
Just sometimes, it’s useful to SSH into a Docker Container. While docker exec or docker attach are usually sufficient to run commands in a container, sometimes you specifically need SSH. For example, to connect directly from a remote machine or when an application needs to run commands on your container. Most Docker images don’t come with the SSHd service installed so it is not possible to SSH to them. This post demonstrates how to install and run the SSHd service to an existing image so that you can connect to it.
A standard unit testing problem is how to unit test code that has a dependency on dates or times. Consider a method that returns a greeting according to the time of day. If we were to call this method from a test fixture (say JUnit), it would return different values depending on when the test was run. This is not ideal. Unit tests should pass or fail consistently.
Here’s a simple solution for testing time based code.
In previous articles, I’ve described how to test System.out with JUnit and how to test log4j with JUnit. This article describes how to test log4j2 logging with JUnit. This largely follows the same technique as testing log4j logging but using the the newer log4j2 APIs. Differences between log4j and log4j2 log4j2 follows a similar design read more
Following a recent article on how to Test System.out with JUnit, here’s a follow up on how to test log4J with JUnit. This article describes a technique to test log4J output in a JUnit test by adding a custom appender. This allows us to verify that log4j output contains expected Strings.
JSPs compile to Java code at run time. This is helpful if we want to test code changes without a build and deploy. However, if errors are introduced, they may not be spotted till it’s too late. A useful compromise is to validate JSPs at build time to verify that they will compile. The validator catches syntax errors before the application deploys and starts. This speeds up our build and test cycle and prevents silly mistakes slipping through to production code.
Thymeleaf is a popular templating engine, particularly with Spring projects. Spring Boot has chosen Thymeleaf as the view technology of choice, largely replacing the need for JSP. With old JSPs, custom tag libraries provided integration with various technologies, including Spring Security. A similar library exists to integrate Thymeleaf and Spring Security – the Thymeleaf Spring read more
It can be useful to verify output to System.out in a unit test. For example, if you’re testing application logging or if you’re using log output to sense some other behaviour. It can be tricky to properly mock behaviour of System.out but fortunately, it is possible to test System.out using JUnit.
Spring Boot Actuator provides assistance for application monitoring. Out of the box it provides information on application health, configuration and logging. It’s trivial to enable: simply add the spring-boot-starter-actuator dependency to a Spring Boot project in Maven or Gradle and it just works! The monitoring information is provided as JSON from HTTP endpoints or via JMX.
The Spring Boot Actuator trace endpoint is particularly handy. By default it shows the last 100 HTTP requests made to the application. This article walks through an Actuator demo and shows some of the configuration options to get the best from this feature.
Like a many things in Tomcat, there are a number of ways to enable remote debugging. Here’s the easiest way I’ve found to enable remote debugging in a Docker container running Tomcat.
