Hey 안상혁,

Sounds reasonable, thanks for the explanation.
I looked around the code and found
`org.apache.kafka.streams.state.HostInfo` class which among other
things parses `application.server` and has some validation. Would it
make sense to use it or its logic for the proposed validation as well?

On Thu, Nov 27, 2025 at 3:16 AM 안상혁 <[email protected]> wrote:
>
> 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?
>

Reply via email to