What’s New in Arconia 0.29.0

The profiles that Arconia activates automatically in dev and test mode can now be customized (or disabled) via the new META-INF/arconia-bootstrap.properties file, checked in with your application. For example, you can use it to activate a local profile instead of the default dev one when running the application in dev mode (arconia.dev.profiles=local). The mode-specific profiles are now activated before Spring Boot loads the application configuration, so profile-specific configuration files are processed as part of the standard Spring Boot configuration flow, including when importing configuration from external sources like Spring Cloud Config Server or HashiCorp Vault. As a consequence, the arconia.dev.profiles, arconia.test.profiles, and arconia.bootstrap.profiles.enabled properties are no longer supported in application.properties/application.yml. You can define them in the new bootstrap configuration file, as JVM system properties, as environment variables, or as command line arguments. Learn more in the Profiles documentation.

Dev Services can now be shared across multiple applications running simultaneously during development, allowing them to use the same containerized service instead of starting one container each. When sharing is enabled, the application connects to a running shared Dev Service started by another application if available, or else starts its own that other applications can discover in turn. Sharing is supported by the Artemis, Docling, Grafana LGTM, Kafka, Ollama, OpenLit, OpenTelemetry Collector, Phoenix, Pulsar, and RabbitMQ Dev Services, is enabled by default, and can be controlled via the arconia.dev.services.<service-name>.shared property. The devservices actuator endpoint now shows whether each Dev Service runs in a container started by the application (OWNED) or discovered from another application (DISCOVERED). Learn more about Sharing Dev Services.

Support for keeping Dev Services running across application restarts and executions has been consolidated on the Reusable Containers feature of Testcontainers, available for all Dev Services via the new arconia.dev.services.<service-name>.reuse property (disabled by default). This replaces the previous behavior of the shared property, which now controls the sharing feature described above (and is only available on the Dev Services that support it): if you relied on shared to keep containers running across restarts, set the reuse property instead. Learn more about Reusing Dev Services Across Restarts.

Dev Service containers can now join a shared network to communicate with each other directly, for scenarios where one containerized service needs to reach another (for example, a Docling Dev Service sending telemetry to a Grafana LGTM Dev Service). Enable it with the global arconia.dev.services.network.enabled property (disabled by default); when enabled, all Dev Service containers join the network and are reachable by their service name. Containers started by different applications running simultaneously can be connected too, by setting a stable network name via the arconia.dev.services.network.name property. Your application’s own connections to Dev Services, over the local host and mapped ports, are unaffected. Learn more about Shared Networks.

Dev Services now log a consistent startup message for each service, listing its resolved links such as management consoles and telemetry endpoints (also available through the devservices actuator endpoint), replacing the ad-hoc lines previously emitted by the underlying container classes. And when a container fails to start, its logs are written to the application log to make an otherwise opaque failure diagnosable, at the level set by the new arconia.dev.services.startup.log-level property (default info; off to disable). Learn more about Startup Feedback.

Configuration errors are now detected at startup instead of being silently ignored. Mutually exclusive Dev Services (for example, two JDBC databases) are reported with an actionable error message before any container is started. Invalid values for the enabled properties result in a bind error, and out-of-range fixed ports are rejected instead of silently falling back to a random port.

Dev Service containers can now be customized programmatically by declaring DevServiceContainerCustomizer beans, applied to matching containers before they are started. This unlocks advanced scenarios not covered by configuration properties, such as defining a custom wait strategy or fine-tuning any other aspect of the underlying Testcontainers object. Learn more in the Dev Services documentation.

You can now build your own Dev Service for any service that can run as an OCI container, using the same infrastructure the built-in Dev Services are based on. The @ConditionalOnDevServicesEnabled annotation accepts a custom configuration property namespace (e.g. @ConditionalOnDevServicesEnabled(name = "fancydb", prefix = "acme.dev.services")), so custom Dev Services get the same activation semantics as the built-in ones: activation in dev and test mode only, the global arconia.dev.services.enabled kill switch, and a service-specific toggle under your own namespace. Learn more in the Building Your Own Dev Service documentation.

The RabbitMQ Dev Service now uses dedicated default credentials (username arconia, password arconia) instead of the RabbitMQ default guest user, consistently with the other credential-protected Dev Services. The credentials can be customized via the new arconia.dev.services.rabbitmq.username and arconia.dev.services.rabbitmq.password properties, are automatically wired into your application, and are required when logging into the RabbitMQ Management Console.