-
Bug Report
-
Resolution: Fixed
-
L3 - Default
-
spring-boot 3.3.1
What are the steps to reproduce your problem?
- Consider having an EnginePlugin that registers an HistoryEventHandler by
configuration.setHistoryEventHandler(historyEventHandler);
- Add this plugin as a component to the spring context
What is the problem?
This obviously overrides the content of the field ProcessEngineConfiguration#historyEventHandler which, since camunda-bpm-spring-boot-starter-3.3.1, contains a CompositeHistoryEventHandler holding two handlers, among them a handler to integrate with SpringEventing.
Setting an individual HistoryEventHandler as described above thus, removes those handlers from the engine config again.
Moreover, it is impossible to securely add the individual handler through CompositeHistoryEventHandler.add() as the collection of handlers already contained in the composite is entirely unaccessible apart from that very adder method.
What would be the expected behavior:
Adding an individual history event handler should add the handler to a CompositeHistoryEventHandler through a consitent API.
Hints (optional):
Moreover, the following would be very helpful
- having a method boolean <T extends HistoryEventHandler> CompositeHistoryEventHandler::contains(Class<T> clazz);
- having an accessor for the elements the list of history event handlers contains
This is the controller panel for Smart Panels app
- duplicates
-
-
- Closed
-
1.
|
Custom History Event Handlers do not overwrite the default |
|
Closed | Unassigned |