Problem

Currently, as I understand, the container details are available through the beans of abstraction ConnectionDetails.

We know that DC (docker compose further) is used for local development so if connection details are required in runtime it makes developers write a code under a specific local profile, which is okay. But this code is basically the mapping, i.e. properties propagation. At the same time in Spring, we love to pass the properties dynamically in *yaml/.properties.

For example, in a similar library playtika spring-boot testcontainers we can pass them dynamically, e.g. embedded.mongodb.*.

I'd like to be able to propagate the properties of the running container to Spring code through properties files. So I can have just an application-local.yml file

Example:

spring.data.mongodb:
  uri: mongodb://${spring.docker.compose.mongodb.host}:${spring.docker.compose.mongodb.port}

Comment From: wilkinsona

Thanks for the suggestion. Unfortunately, there's a chicken and egg problem here. Properties are used to configure the Docker Compose support so the environment has to have been prepared before the Docker Compose support can run. This makes it too late for that support to then add properties to the environment.

If you want to access the properties that are retrieved from the running containers, you should inject the relevant …ConnectionDetails bean. This will allow the details to be consumed in a consistent way, no matter where they've come from (Docker Compose, Testcontainers, properties in the environment, or a custom …ConnectionDetails bean).

Comment From: artemptushkin

@wilkinsona thank you for answering quickly I had considered this I think, I actually wanted to ask why with this request as I'm a curious Spring Boot developer.

I know that in playtika starter they expose new properties after the container is started, isn't it not possible to do it in Spring too?

Comment From: wilkinsona

I'm afraid not.

The Playtika Testcontainers support depends on Spring Cloud. It uses its bootstrap context (a separate application context that's started very early) to get things up a running and then adds properties to the main context. In terms of the lifecycle and adding properties to the environment, this is similar to what Spring Cloud Config server does.

When designing Spring Boot's service connection support, we didn't want to require a separate application context for bootstrapping, and we had the luxury of being able to avoid that by introducing the ConnectionDetails abstraction. This is lighter weight than requiring another application context, and, as I described above, also has the benefit of allowing the connection details to be accessed in a consistent manner, irrespective of their source.