I started wrapping zeebe with spring boot and find it very hard to configure because of the TOML format …
why is this used and couldn’t we just use a Pojo representation so it does not care which text-input I prefer?
Limiting zeebe to only java will certainly lead to a nogo decision for me.
Hi Jan.
Wrapping the broker & starting it yourself is not a designated use case, as the broker typically runs as separate process. That’s why it is not meant to be easily configurable via Spring. I also think that starting the broker itself via Spring Boot is not the use case we should aim for (there is also not the option to start the Kafka broker even if you have Kafka support). That’s said it is easy to hand in Properties - so you could read the configuration from some other configuration management tool.
Cheers
Bernd
1 Like
Hi Olivier.
What makes you think that Zeebe is limited to Java?
Cheers
Bernd
Ok, thanks, Bernd. While what you said is true, I hope that making it hard to configure via spring was not the sole motivation for chosing TOML over YAML or JSON (which I would have assumed a natural choice) …
Hi Bernd,
Up to there nothing for Zeebe.
But configuring with pojo leads to enforcing the library to be stuck to a programming language.
I have seen that in wordpress, symfony, zend framework … spring ?!
And every time, even beginning with good intentions, these lead to increase technical debt and decrease price-quality ratio.
I hope something like the 12 factors will be followed somewhere.
One could configure with env, ini or toml. But not only with pojo.
Anyway, thanks for your quick feedback
Don’t worry!
Supporting polyglot landscapes is one of the fundamental design goals of Zeebe. We also started a golang client and discuss with golang users from the beginning to enforce it.
Hi all,
thank you for you helpful feedback
@jangalinski as Bernd wrote: with Spring Boot we should initially focus on embedding and configuring the Java Client in a Spring / Spring Boot application. The broker, you should think about it like MySQL, Kafka, RabbitMQ Broker, … it is a server which sits there and is started directly or within a Docker etc …
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?
Hi Jan,
Would you be open for a PR where I demonstrate this in code?
Maybe you can demonstrate or outline what would be important for your use case without investing to much time into this. To better support cloud environments we will probably have to add support for (partially) configuring Zeebe using environment variables. So maybe we can also improve the support for your use case.
Cheers,
Sebastian
Well, the general idea is quite simple.
- configuration parameters are specified by a POJI/O
- The Broker accepts the POJI as constructor parameter (or, as with camunda, the POJI provides a build method for the broker)
- a configurationFactory interface is provided that allows to create a POJO implementation of the config interface
- various factories exist or can be implemented, where TOML is the currently supported default, ENV might follow, but, and thats the benefit, by just using @ConfigurationProperties in spring I can also use the full power of springs external configuration if I want to (yaml, properties, config server, cli, defaults, expressions, profiles, …)(https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html)
so imho: very low invasion (just one more step in the constructor chain) but high impact and flexibility. Plus: possible to validate/inspect/print the configuration
Thanks for your input Jan 
As a last remark: I agree that we should have a feature to configure the broker problematically. Even if started as own process I know of configuration management tools customers use which can easily deliver java.util.Properties but have more problems with TOML. But I think it is currently no top priority.
well, properties2pojo is just another factory in my picture …
like the typo. “configure problematically”
So … should I create a PR for this?
@jangalinski pull requests are always welcome, but for this topic maybe give us some time to come up with something as it probably requires a lot of refactoring and boiler plate and we don’t want to waste your time