Hi Nikita! Thanks for the thoughtful feedback. Your points are very valid. Here are my thoughts on your questions:
1. Regarding the warning and application functionality: Today, if application.server is malformed, Kafka Streams fails later when constructing the KafkaStreams instance, and the application does not run. In Phase 1, I am not changing that behaviour. The application will still eventually fail at the same point as it does today. The only change is that StreamsConfig will additionally log a warning when it detects an invalid application.server value. The intention is to give users an early signal that in a later version (Phase 2) this will become a hard failure during config initialization. In Phase 2, the same validation will move from the KafkaStreams constructor into the config layer, and will throw at init time instead of at runtime. 2. Regarding the validation logic : I completely agree that trying to cover all possible host formats with a single regex is brittle and likely to be both incomplete and overly permissive. The goal here is not to check reachability or DNS existence, but simply to enforce a minimal syntactic structure. To address this, I am planning to simplify the validator to a syntax-only check: ensure the string contains at least one colon separator take the substring after the last colon and verify that it is a valid integer port This way, we can fail fast for clearly malformed values that do not have any port component, while avoiding the complexity and pitfalls of validating all possible host formats. What do you think about this more relaxed, syntax-only validation approach?
