[Other]: Allow dev services to override startup and wait strategies via Spring beans

[jimisola]

Description

Summary

Arconia dev services use fixed startup and wait strategies to determine container readiness.
These strategies cannot currently be overridden.

This can be limiting in scenarios where the default startup or wait strategy does not match the actual behavior of the container being run. This may happen for a variety of reasons, for example:

• Running a generic container with non-standard startup behavior
• Environment-specific differences in container behavior
• Changes in container configuration that affect readiness signals

In one concrete case, PostgreSQL was run in an environment where file permission constraints required changes to the container setup. While the container itself started correctly, the resulting startup behavior no longer matched the assumptions made by the existing startup strategy, causing the dev service to never be detected as ready.

At the moment, there is no supported way to override startup or wait strategies while still using Arconia’s dev services.

Proposed Change

Allow dev services to reference custom startup and wait strategies via configuration.

Strategies must be:

• Implementations of the existing strategy interfaces
• Managed as Spring beans
• Resolved from the Spring ApplicationContext

This allows users to adapt readiness behavior without reimplementing or forking dev services.

Example configuration:

arconia:
  dev-services:
    postgresql:
      enabled: true

      wait-strategy: com.example.CustomPostgresWaitStrategy
      startup-check-strategy: com.example.CustomPostgresStartupStrategy

Configuration Shape

The configuration contains references to strategy implementations:

private /* reference */ waitStrategy;
private /* reference */ startupCheckStrategy;

The exact reference type is intentionally minimal.

Resolution Rules

• Strategies are resolved only via Spring
• No reflective instantiation is performed
• Resolution fails fast if:
  • No matching bean exists
  • The bean does not implement the expected strategy interface
  • Resolution is ambiguous

Strategy Resolution (Implementation Detail)

Resolution logic may be centralized in an internal component, for example:

interface StrategyResolver {
    <T> T resolve(Object reference, Class<T> expectedType);
}

This component would:

• Encapsulate Spring lookup logic
• Enforce type safety
• Provide consistent error handling

This is an internal detail and not part of the public API.

Reference Format

Two reference formats are viable:

• Fully qualified class name of the strategy implementation
• Spring bean name

The initial implementation may support one or both. The decision should favor:

• Simplicity
• Clear error reporting
• Minimal configuration surface

Configuration Binding Considerations

If fully qualified class names are used, configuration binding may use:

• String
• Or Class<? extends Strategy> if supported by Spring Boot configuration binding

The chosen approach should align with existing Arconia configuration practices.

Lifecycle Hook Before Container Start

Startup and wait strategies must be configured before the container’s start() method is invoked. Once startup begins, it is no longer possible to reliably change readiness behavior.

Because of this, approaches such as BeanPostProcessor are not suitable, as they run after bean instantiation and often after container startup has already occurred.

This raises the question of where and how Arconia should expose a common hook that runs before container startup, similar in spirit to how BeanPostProcessor provides a well-defined interception point for Spring beans.

Such a hook would:

• Run before start() is called on the container
• Allow dev services to customize startup-related behavior in a consistent way
• Provide a centralized extension point instead of ad-hoc service-specific logic

This hook would be internal and lifecycle-focused, not a general-purpose bean extension mechanism.

Scope

• Applies to all dev services

Acceptance Criteria

• Startup and wait strategies can be overridden via configuration
• Custom strategies can be applied to both built-in dev services and generic containers
• Only Spring-managed beans are used for strategy resolution
• Misconfiguration results in clear startup errors
• Documentation includes at least one example overriding a dev service strategy