-
Task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
Skip: The required behavior can be reached by replacing the RuntimeContainerDelegateImpl. But I isolated the step configuration to make overwriting easier. see https://github.com/camunda/camunda-bpm-platform/pull/254
Note: This is mainly an issue for the spring boot extension but might also leed to a more open and flexible configuration system.
Story: As developer, I want to set up and configure a camunda spring boot application without using an additional xml file. It should be enough to just have application.properties|yaml.
What blocks this? When using a ProcessApplication, the RuntimeContainerDelegateImpl takes care of setting up deploymentOperationsSteps. These are hardcoded and not configurable.
Problem is the first step: "ParseProcessesXmlStep". This is able to return a default ProcessesXml instance or read the xml file. But it cannot deal with "no processes.xml but properties".
My first thought was to get inside this step, do some "if/else" config and switch based on ENV properties existing and so on.
But then: it does not feel right.
What I would love to have is to read the required steps form some kind of configuration, so I could just overwrite the ParseProcessesXmlStep with a custom implementation.
What do you think of having a List of DeploymentOperationSteps on the ProcessEngineConfigurationImpl? I could thean just provide my own list of steps and I am done.
Another option would be to have those steps on the processApplication directly, So the AbstractProcessApplication would have a list of steps and my custom Application would overwrite this list.
This is the controller panel for Smart Panels app
[CAM-6937] Allow process application deployment without processes.xml - pluggable DeploymentOperationSteps
Hm ... after further analysis ... if I would replace RuntimeContainerDelegateImpl completely with a custom implementation via
RuntimeContainerDelegate.INSTANCE.set(myImplementation);
that should already do the trick.
Although configuring the steps and executing them could still be 2 different methods so overwriting is more isolated.
| Description |
Original:
Note: This is mainly an issue for the spring boot extension but might also leed to a more open and flexible configuration system. Story: As developer, I want to set up and configure a camunda spring boot application without using an additional xml file. It should be enough to just have application.properties|yaml. What blocks this? When using a ProcessApplication, the RuntimeContainerDelegateImpl takes care of setting up deploymentOperationsSteps. These are hardcoded and not configurable. Problem is the first step: "ParseProcessesXmlStep". This is able to return a default ProcessesXml instance or read the xml file. But it cannot deal with "no processes.xml but properties". My first thought was to get inside this step, do some "if/else" config and switch based on ENV properties existing and so on. But then: it does not feel right. What I would love to have is to read the required steps form some kind of configuration, so I could just overwrite the ParseProcessesXmlStep with a custom implementation. What do you think of having a List of DeploymentOperationSteps on the ProcessEngineConfigurationImpl? I could thean just provide my own list of steps and I am done. Another option would be to have those steps on the processApplication directly, So the AbstractProcessApplication would have a list of steps and my custom Application would overwrite this list. |
New:
Skip: The required behavior can be reached by replacing the RuntimeContainerDelegateImpl. But I isolated the step configuration to make overwriting easier. see https://github.com/camunda/camunda-bpm-platform/pull/254 Note: This is mainly an issue for the spring boot extension but might also leed to a more open and flexible configuration system. Story: As developer, I want to set up and configure a camunda spring boot application without using an additional xml file. It should be enough to just have application.properties|yaml. What blocks this? When using a ProcessApplication, the RuntimeContainerDelegateImpl takes care of setting up deploymentOperationsSteps. These are hardcoded and not configurable. Problem is the first step: "ParseProcessesXmlStep". This is able to return a default ProcessesXml instance or read the xml file. But it cannot deal with "no processes.xml but properties". My first thought was to get inside this step, do some "if/else" config and switch based on ENV properties existing and so on. But then: it does not feel right. What I would love to have is to read the required steps form some kind of configuration, so I could just overwrite the ParseProcessesXmlStep with a custom implementation. What do you think of having a List of DeploymentOperationSteps on the ProcessEngineConfigurationImpl? I could thean just provide my own list of steps and I am done. Another option would be to have those steps on the processApplication directly, So the AbstractProcessApplication would have a list of steps and my custom Application would overwrite this list. |
| Fix Version/s | New: 7.6.0 [ 14490 ] |
jan.galinski@holisticon.de, I guess this issue is resolved with the merge of your pull request, or? can we close it?
| Issue Type | Original: Feature Request [ 2 ] | New: Task [ 3 ] |
| Assignee | New: Askar [ askar.akhmerov ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
The spring boot extension would really benefit from this ... so I'd love to have the "plugin" mechanism in 7.6. It would be then part of the extension to provide an implementation. Basically like we already did with the SchemaOperations ...