I totally get the point, that the broker should run standalone. But I’d still prefer if the configuration of a component (Broker/Client) would be represented by a Pojo (like the ProcessEngineConfiguration in camunda). So the Broker would have an additional (main) constructor accepting a brokerConfiguration and other constructors )or factory methods) deal with reading this pojo from various text representations, where the only “officially” supported is TOML.
Benefit: if you want to include client/broker in a (spring boot)-app, you are free to chose the configuration representation as long as you are able to create a valid broker/clientConfiguration from it.
You could easily validate if the configuration meats all required criteria, apply defaults and use it to log the startup params. It wouldn’t hurt much, wouldn’t break the existing setup but allow more flexibility.
Besides that, I personally believe that wrapping the broker (plain java service) in a spring-boot application would not interfere with the broker architecture and runtime but could allow nice addons, like providing a metrics service or using spring-cloud standards like eureka-discovery and configuration via config-server, which I actually miss when working with kafka/rabbit/…)
Would you be open for a PR where I demonstrate this in code?