Configuring Java version in a Maven based app

There’s a couple of different ways to configure the Java version for an app in your Maven pom.xml file.

The simplest is with the following properties:

<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>

If you’re configuring a Spring Boot app with Maven, you can also use this single property (only works for a Spring Boot app using the starter parent spring-boot-starter-parent) to override the Spring Boot default:

<properties>
<java.version>17</java.version>
</properties>

VMWare Fusion Pro for MacOS and Workstation Pro for Windows now free for personal use

Following Broadcom’s buyout of VMWare, many home users of virtualization software such as VMWare’s ESXi were disappointed that the free personal use was discontinued.

News today however is more promising: from today you can download Fusion Pro for MacOS and Workstation Pro for Windows free for personal use. You need to sign up for an account at support.broadcom.com and then search for either product to download. More details here.

Deploying a Docker container to AWS Elastic Beanstalk

In my previous post, I looked at using the EB cli to deploy a Spring Boot app to Beanstalk. If you have an app that you have packaged in a Docker container, you can prepare this for deployment to Beanstalk using the EB cli command:

$ eb init -p docker application-name

This is described in the docs here.

This command inits the app for deployment, creating a default .elasticbeanstalk/config.yml file that looks like this:

branch-defaults:
default:
environment: null
group_suffix: null
global:
application_name: beanstalk-docker-with-mounted-volume
branch: null
default_ec2_keyname: null
default_platform: Docker
default_region: us-west-2
include_git_submodules: true
instance_profile: null
platform_name: null
platform_version: null
profile: null
repository: null
sc: null
workspace_type: Application

Next create a Beanstalk environment for deploying your app:

$ eb create environment-name

This will take a few minutes on your first deploy as it provisions everything required for running your app on Beanstalk, including an Auto Scaling Group and an EC2 instance.

Using WireMock with Spring Boot 3 and JUnit 5

To use WireMock with JUnit 4.x you use a @Rule statement to configure the WireMock server:

@Rule
public WireMockRule wireMockRule = new WireMockRule();

With JUnit 5, @Rule was replaced with extensions, so the equivalent setup looks like this:

@RegisterExtension
static WireMockExtension wm1 = WireMockExtension.newInstance()
.options(options().port(8089))
.build();

Testing Spring Boot 3 apps with JUnit 5 however gives the following error as Spring Boot 3 does not have Jetty 11 dependencies, so WireMock’s use of Jetty 11 fails to start:

com.github.tomakehurst.wiremock.common.FatalStartupException: Jetty 11 is not present and no suitable HttpServerFactory extension was found. Please ensure that the classpath includes a WireMock extension that provides an HttpServerFactory implementation. See http://wiremock.org/docs/extending-wiremock/ for more information.
at com.github.tomakehurst.wiremock.WireMockServer.lambda$getHttpServerFactory$2(WireMockServer.java:95)

Per the WireMock docs here, wiremock-spring-boot provides support using another approach. To use, add this dependency:

<dependency>
<groupId>com.maciejwalkowiak.spring</groupId>
<artifactId>wiremock-spring-boot</artifactId>
<version>2.1.2</version>
<scope>test</scope>
</dependency>

Enable for your test by adding @EnableWireMock:

@SpringBootTest
@EnableWireMock({
@ConfigureWireMock(name = "your-mock-service", property = "your-url-to-mock.url")
})
class YourTest {
...
}

Inject the WireMock server into your test with:

@InjectWireMock("your-mock-service")
private WireMockServer wiremock;

@Value("${your-url-to-mock.url}")
private String wiremockUrl;

While this is a neat option to use with SpringBootTests, unfortunately it still doesn’t work with Spring Boot 3.3.x because of WireMock’s dependency on Jetty 11.

Tickets posted on the wiremock-spring-boot project suggest to avoid this in the meantime by using a dependency for wiremock-standalone instead:

        <dependency>
<groupId>com.maciejwalkowiak.spring</groupId>
<artifactId>wiremock-spring-boot</artifactId>
<version>2.0.0</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.wiremock</groupId>
<artifactId>wiremock</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.wiremock</groupId>
<artifactId>wiremock-standalone</artifactId>
<version>3.3.1</version>
<scope>test</scope>
</dependency>

This works as expected.