Consider to expose a `spring.kafka.bootstrap-servers` System property with `EmbeddedKafkaBroker`

[artembilan]

Some context here: https://stackoverflow.com/questions/76731694/springkafkatest-embeddedkafka-why-is-brokerproperties-necessary

It looks like community always struggle with an @EmbeddedKafka and Spring Boot combination. They just miss the fat to remap an internal property to the spring.kafka.bootstrap-servers like we explain in docs: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#messaging.kafka.embedded.

I believe it won't hurt to expose that spring.kafka.bootstrap-servers into System properties alongside with configured EmbeddedKafkaBroker.brokerListProperty.

This way Spring Boot testing with an embedded Kafka experience would be much smoother and will confirm that Spring project works well together.

Another way would be probably something like an EnvironmentPostprocessor on Spring Boot side to remap internal property to an auto-configuration one, like it is shows in SO mentioned above:

spring.kafka.bootstrap-servers=${spring.embedded.kafka.brokers}

Or this might be done by the ContextCustomizerFactory for test scope only.

After more thinking it is hard now to convince me that exposing spring.kafka.bootstrap-servers string into system properties makes semantical dependency between Spring for Apache Kafka and Spring Boot.
What if we would decide in the beginning to use this name for default property?
The simple change for respective string would make it much easier to support everything from now on. In comparison to how many similar questions we have to answer same way and how much work is needed to be done on Spring Boot side to expose this by default.

[garyrussell]

I think we could just change the default in the annotation (but not in the broker itself, to avoid breaking existing apps).

[garyrussell]

After further thought; this could break existing applications; must defer to 3.1.0.

[artembilan]

Correct. That's why I thought about addition system property which would not break current apps if they rely on the old property.
It also won't break existing apps which are already remapping to Spring Boot one explicitly.
However, new projects won't suffer an extra work to find out why Spring Boot tests don't work with an Embedded Kafka as is.

[garyrussell]

Oh; right; I guess we can change the logic to set the default property, as well as the boot property.