Switch from @EnableZeebeClient to Spring Boot Auto-Configuration

[berndruecker]

I recently added Metrics to Spring-Zeebe and wanted that the user application can bring its own implementation of a MetricRecorder. Therefore, the core library would ship with a NoopMetricsRecorder. I tried to use Spring Configuration magic for this, to only create the NoopMetricsRecorder if no other MetricsRecorder is defined (e.g. @ConditionOnMissingBean). This did not work as expected and it took me a while to figure out the root cause, which is very well explained here: spring-projects/spring-boot#18228

Bottom-line:

• The design using an @EnableZeebeClient annotation bypasses the Spring Auto Configuration mechanism
• This means, you cannot easily swap out beans by the mechanisms documented by Spring (or found via Google) - at the same time it is not very obvious why those solutions do not have any effect
• For my MetricsRecorder at hand I now use the workaround @Autowired(required = false) MetricsRecorder and create the Noop only if null is handed in. This works, but does not feel right.

Now I think we should change spring-zeebe:

• Deprecate @EnableZeebeClient
• Add spring.factories in meta-inf to automatically enable the Zeebe Client if the library is on the classpath
• Add a configuration option zeebe.client.enabled which can be set to false to disable the client if needed

Why?

• I don't see any situation where you add spring-zeebe to the classpath but not want the client to be enabled
• Using Spring Auto Configuration would ease up a lot of configuration work and make it easier understandable. We already hit problems around this in the past.

Does anybody see any problems with this?
8.2.x would be a good candidate to make such a change. It would generally work backwards compatible, unless somebody has an application that pulls in spring-zeebe-starter, but does not add @EnableZeebeClient. We could log a BIG WARNING in such a case to raise awareness for those situations (which should be very rare).

One open question is:

• Can we make spring-zeebe dependent on Spring Boot? This might be necessary to use auto configuration. The result is, that spring-zeebe would always depend on Spring Boot, right now spring-zeebe depends on spring-context and only spring-zeebe-starter depends on spring-boot.

[berndruecker]

Any thoughts (maybe @lzgabel @aivinog1 @zambrovski @jangalinski @falko)?

• Can we remove @EnableZeebeClient and auto start the client always (unless zeebe.client.enabled=false)?
• Can we make spring-zeebe depending on Spring Boot (instead of just Spring Context)?

[lzgabel]

@berndruecker. For me, I really like your proposal. 🚀

At the same time, I suggest that you can collect other opinions in the C8 slack group.

[zambrovski]

Hi Bernd.

I believe the AutoConfiguration is a better way of infrastructure setup than simple @enable... annotations. Its application needs to be done with care. So to answer all your questions:

• Yes, I vote for AutoConfiguration activated by spring.factories starting the client always.
• Yes, I vote for a property to switch it off entirely, so the @AutoConfiguration should be skipped if the property is explicitly set to false.
• Be careful, there are not only applications out there using this library, but also other framework / tool builder. They might want to include your code on the classpath and not switch it on.
• Make sure the activation of beans works based on the principal of a @ConditionalOnMissing bean.
• Never declare @Primary beans ins the library itself, otherwise others can't replace it.
• Now the important one IMHO: the functional core SHOULD be independent from the autoconfigure or starter module. There will be people who wants to use your functional code, but configure it differently - don't force them to do it your way. Let spring-zeebe depend on spring-context only and add spring-boot dependency to the starter only.
• @Deprecation: the next version should introduce the @Deprecation notice on the class and maybe produce a WARNING in the log that the @EnableSpringZeebe annotation is the wrong way. In the following versions, we might decide to entirely delete the class.

[jangalinski]

+1 to what Simon said. Having a "spring only" core and an additional spring-boot autoconfiguration/starter is a good idea.

[berndruecker]

Thanks @zambrovski!

There will be people who wants to use your functional code, but configure it differently
Do you have a specific use case in mind? The thing is, that there are a lot of things already mixed (Job Handling, Exception Handling Strategy, Metrics, ...) that make it hard o wire without Spring Boot in an exchangeable way. Or to put it in another way: I don't think there will be a very valuable core left and could imagine it makes more sense to go "all in"? Maybe worth a quick Zoom discussion some time in December?

[namero999]

I don't have a grip on the internals, so can't judge the viability, but the ability to use the lib in a non-Boot context seems quite desirable.

[berndruecker]

Also revisit @lazy of MetricsRecorder, see #296 and #297

[berndruecker]

Look at lifecycle of ZeebeClient, it is currently created very late, see #313

[berndruecker]

Probably related (or at least could be fixed differently then: camunda-community-hub/camunda-8-benchmark#59)

[berndruecker]

Created #353 which looks good so far 👍