Jan Galinski added a comment - 07/Nov/16 7:14 PM See https://github.com/camunda/camunda-bpm-platform/pull/255

Askar added a comment - 08/Nov/16 3:05 PM Hi jan.galinski@holisticon.de , could you please elaborate a bit on the use-case? I am not sure I follow why would it be useful. One more thing about pull request, if one would register all plugins and then also register composite plugin all methods will be executed twice. This is a bit confusing.

Jan Galinski added a comment - 08/Nov/16 3:28 PM - edited Of course. Have a look at https://github.com/camunda/camunda-bpm-spring-boot-starter/tree/master/extension/starter/src/main/java/org/camunda/bpm/spring/boot/starter/configuration In the spring boot extension, we use ProcessEnginePlugin#preInit a lot to configure the processEngine. We collect all known plugins of a certain type and register them on the engineConfiguration. This is a very nice way to separate concerns of configuration since the processEngineConfigurationImpl is very bloated. I also adopted this pattern in our current customer project where we do not use spring boot but use many small plugins to configure the different aspects. Whats annoying is that on startup the engine logs every single plugin like this: 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'HistoryLevelPlugin' activated on process engine ' default ' 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'DataSourcePlugin' activated on process engine ' default ' 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'ReactorProcessEnginePlugin' activated on process engine ' default ' 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'ImmutableExpressionManagerPlugin' activated on process engine ' default ' 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'JobExecutorPlugin' activated on process engine ' default ' 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'MetricsReporterPlugin' activated on process engine ' default ' The idea is to have one CompositePlugin registered that than executes a bunch of other plugins, so it will look like this: 2016-11-08 14:21:05 [main] INFO org.camunda.bpm.engine.cfg - ENGINE-12003 Plugin 'EngineConfigurationPlugin[DataSourcePlugin, ReactorProcessEnginePlugin,ExpressionManagerPlugin, JobExecutorPlugin, MetricsReporterPlugin]' activated on process engine ' default ' I believe this will push the plugin-for-configuration-approach forward and lead to better readability and acceptance. With your concern about executing twice ... you are right. But thats a misconfiguration of the plugin mechanism that can happen without composite any time. Just add a plugin twice ... so I think this does not really count. My assumption is that this does not really hurt in general but provides better usability in some use cases (on framework level, I could provide pre-bundled plugins that serve multiple purposes (setting up a complete integration test environment for example) without documenting in detail which plugins to include or which configuration properties to set. So I really hope that this can make it to the core. If you decide to decline this one, I will have to include it in the spring boot extension directly, but as I said: it is not spring boot specific. Its more related to the CompositeHistoryEventHandler or the CompositeElResolver (which both share the risk of redundant execution due to misconfiguration). Does that help?