What’s New in Arconia 0.31.0

Dev Services can now serve SSL, so that the SSL support of your application is developed and tested against them. Set the ssl.enabled property of a Dev Service and configure the certificate it presents with the keys of a Spring Boot SSL bundle, in PEM or Java keystore form: the container is configured to serve SSL, and the application is configured to trust it through the service connection, with nothing to set up on the client side. The bundle is reported by the startup log and the devservices actuator endpoint, and registered in the SslBundles of the application. Learn more about SSL with Dev Services.

The arconia.dev.services.<name>.reuse and arconia.dev.services.<name>.shared properties of each Dev Service have been replaced by a single arconia.dev.services.<name>.reuse-strategy property, since both answered the same question: whether to use a container that is already running instead of starting a new one. It accepts framework (previously shared=true), testcontainers (previously reuse=true), and none. Learn more about Reusing Dev Services.

The framework reuse strategy is now supported by all the Dev Services.

When your application defines its own ConnectionDetails bean of the type a Dev Service provides, such as a JdbcConnectionDetails bean, the Dev Service is no longer started, and a message says so at startup: the application connects to the service of your choice. Learn more about Service Connections.

The arconia.dev.services.startup.log-level has been removed because redundant since Testcontainers already takes care of writing a failed container’s logs to the application logs at error level.

The arconia.dev.services.network.name property has been removed, since Arconia no longer manages networks shared across applications: by default, the shared network is isolated per application and is created and removed by Testcontainers. To have the Dev Services join a network you manage, define your own Network bean, which takes precedence over the one Arconia provides. Learn more about Shared Network.

ContainerInfo.exposedPorts() has been renamed to ports(), since it holds the port mappings of the container. The devservices actuator endpoint reports them under ports accordingly. The automated upgrade takes care of it.

The devservices actuator endpoint now reports the state of each container (state) as the container runtime reports it, such as running or exited. Learn more about the Actuator support.

The JSpecify nullability annotations of all Dev Services modules are now enforced with NullAway at build time, so the null-safety contracts your IDE sees are verified rather than declared only.

If you build your own Dev Service, some API changes have been introduced to simplify the registration and configuration of dev services. The registration is now a flat DevServiceSpec, declaring the container, the ports, the links, the discovery, and the SSL support in one place, and the framework applies the common properties to the container, so ContainerConfigurer is no longer needed. Mistakes in the registration, such as two Dev Services with the same name, a missing description, or a port property set for a Dev Service declaring no main port, now fail at startup instead of being silently ignored. Refer to the updated documentation on how to build your own dev service. The automated upgrade takes care of the renamed and moved types and removes the ContainerConfigurer calls, while the registration itself needs to be updated by hand.

The Docling Dev Service now links to the Scalar API reference of Docling Serve at /scalar, next to the Docling UI and the OpenAPI documentation.

The Elasticsearch Dev Service now serves plain HTTP by default. Elasticsearch 8 and later only accept HTTPS in their default configuration, with a certificate the application could not trust, so the Dev Service could not be reached before.

The Elasticsearch Dev Service can now serve SSL, with the certificate configured through its ssl properties, and the application is configured to trust it automatically. With no certificate configured, Elasticsearch keeps the one it generates itself, and the application trusts it the way Spring Boot does for an @Ssl container. Learn more about Using SSL.

The Floci Dev Service now relies on the Floci service connection support of Spring Cloud AWS instead of its own, so it can be used in a project that also depends on spring-cloud-aws-testcontainers, which failed before with duplicate connection details. Since the Dev Service brings the core of Spring Cloud AWS with it, adding the starter of each AWS service in use is all it takes to activate it: an application with an incomplete Spring Cloud AWS classpath no longer fails at startup in its auto-configuration. Learn more about the Floci Dev Service.

The Grafana LGTM Dev Service now provisions Grafana with dashboards for Spring Boot applications, replacing the ones bundled with the image. They are picked for the application: a JVM dashboard comes in a Micrometer or OpenTelemetry variant, depending on the metric conventions in use, and a Logging dashboard shows log events by level next to the application logs. Your own dashboards, and the ones shipped by libraries, are provisioned from META-INF/grafana/dashboards on the classpath, with no configuration needed. You can sign in to Grafana with the arconia/arconia credentials. The dashboards properties let you turn the provisioning off, keep only your own dashboards, or open one of them as the Grafana home page. Learn more about Grafana Dashboards.

The Grafana LGTM Dev Service now enables the MCP server built into Tempo, so that AI coding assistants can query the traces of your application, and links to it next to Grafana and the OTLP endpoints. A Prometheus link has been added as well. Learn more about Using AI Tools.

The documentation of the Grafana LGTM Dev Service now describes how the telemetry of your application reaches the stack and how to customize its components, from their logs and configuration files to forwarding telemetry to another backend. Learn more about Customizing the Stack.

The Kafka Dev Service can now serve SSL, with the certificate configured through its ssl properties, and the application is configured to trust it automatically. Learn more about Using SSL.

A new Keycloak Dev Service provides an identity and access management server for development and testing. It configures Spring Security’s OAuth2 Client and OAuth2 Resource Server automatically, depending on which is on the classpath, so an application needs no OAuth2 configuration to start logging users in or validating tokens. A realm with a client, roles and users is generated out of the box, and you can configure its users and roles, import your own realms from the classpath or the host filesystem, or turn realm creation off entirely and configure Spring Security yourself.

The MongoDB Dev Service can now serve SSL, with the certificate configured through its ssl properties, and the application is configured to trust it automatically. Learn more about Using SSL.

The RabbitMQ Dev Service can now serve SSL, with the certificate configured through its ssl properties, and the application is configured to trust it automatically. The application connects to its AMQPS listener, which the fixed port property then binds. Learn more about Using SSL.

The Redis Dev Service can now serve SSL, with the certificate configured through its ssl properties, and the application is configured to trust it automatically. Learn more about Using SSL.

The Docling integration has been upgraded to Docling Java 0.7, which replaces the DoclingServeApiBuilderFactory SPI with DoclingServeApiProvider. Arconia registers a provider, so the standard DoclingServeApi.builder() entry point now builds the Arconia client, and DoclingServeApi.config() reports the configuration of the auto-configured client, which config().toBuilder() copies. The builder of DoclingServeClient no longer implements the deprecated DoclingApiBuilder interface, and its toBuilder() method is unsupported in favor of config().toBuilder().

The requests sent to Docling Serve and the responses received from it can now be logged with the arconia.docling.log-requests, arconia.docling.log-responses, and arconia.docling.pretty-print properties, with the API key masked.

When the Docling Serve API rejects a request, the Docling client now throws the ValidationException of Docling Java, carrying the validation details reported by the API, instead of a bare HttpClientErrorException.

The executor running the async operations of the Docling client can be customized with the asyncExecutor option of DoclingServeClient.builder() or DoclingServeApi.builder(). Virtual threads are used by default.

The Docling health indicator now reports the location of the Docling Serve instance (its base URL) in the health details, whether the status is UP or DOWN, so that you can tell which instance the application talked to when the check fails. Learn more about the Health Indicator.