You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the support to generate code for TriggerMesh #434 integration when migrating from Mule 3.9 to Spring Boot can be toggled by setting the application property sbm.muleTriggerMeshTransformEnabled.
The behaviour should be changed as this property is more of a recipe/action configuration and should not be on application level.
Why it needs to be done
Instead of using Spring application properties to trigger the behaviour of JavaDslAction2, there should be two variants of the migrate-mule-to-boot recipe, one with TriggerMesh and one without. This would provide a simpler and cleaner user experience to chose different behaviour of a migration.
The problem is that with the current implementation DwlTransformTranslator is configurable to create TriggerMesh or "default" (hints) DWL translation by setting the sbm.muleTriggerMeshTransformEnabled flag.
With the current implementation this flag has to be passed through from the recipe declaration to the Translator to remove the need for the application property.
A solution could be:
Remove the application property
Provide a member in JavaDSLAction to keep the strategy (enum) for Dwl translation
Provide two Translators, one for TriggerMesh and one for previous, default DWL translation.
Refactor FlowTopLevelElementFactory.buildDefinition() to allow passing a strategy (replacing the flag) which defines which of the DwlTranslators gets added to the Map<Class, MuleComponentToSpringIntegrationDslTranslator> translatorsMap.
Uh oh!
There was an error while loading. Please reload this page.
labels: ["type: enhancement","in: mule-3.9"]
What needs to be done
Currently, the support to generate code for TriggerMesh #434 integration when migrating from Mule 3.9 to Spring Boot can be toggled by setting the application property
sbm.muleTriggerMeshTransformEnabled
.The behaviour should be changed as this property is more of a recipe/action configuration and should not be on application level.
Why it needs to be done
Instead of using Spring application properties to trigger the behaviour of
JavaDslAction2
, there should be two variants of themigrate-mule-to-boot
recipe, one with TriggerMesh and one without. This would provide a simpler and cleaner user experience to chose different behaviour of a migration.The problem is that with the current implementation
DwlTransformTranslator
is configurable to create TriggerMesh or "default" (hints) DWL translation by setting thesbm.muleTriggerMeshTransformEnabled
flag.With the current implementation this flag has to be passed through from the recipe declaration to the
Translator
to remove the need for the application property.A solution could be:
JavaDSLAction
to keep the strategy (enum) for Dwl translationFlowTopLevelElementFactory.buildDefinition()
to allow passing a strategy (replacing the flag) which defines which of the DwlTranslator
s gets added to theMap<Class, MuleComponentToSpringIntegrationDslTranslator> translatorsMap
.buildDefinition
methodJavaDSLAction2
into the TriggerMesh Dwl TransformerAdditional Information
The text was updated successfully, but these errors were encountered: