[
https://issues.apache.org/jira/browse/CAMEL-23775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-23775:
----------------------------------
Description:
Camel YAML DSL currently supports built-in route model deserializers and custom
resolvers registered in the Camel registry. However, optional Camel modules do
not have a simple generic way to contribute YAML route step deserializers
automatically when the module is present on the classpath.
This makes it difficult for an optional module to expose a custom YAML route
step without requiring changes in the YAML DSL module itself or requiring users
to manually register YAML resolver beans before route parsing.
This improvement proposes adding a YAML-only extension point that allows
optional modules to provide YAML route step deserializers in a discoverable way.
The goal is to let an optional module contribute support for a custom YAML step
name, map that YAML node to a Camel route model definition, and then rely on
the existing model/reifier/ProcessorFactory mechanisms for runtime behavior.
h3. The implementation should:
* allow optional modules to contribute {{YamlDeserializerResolver}}
implementations;
* discover those resolvers before YAML routes are parsed;
* preserve the existing built-in YAML DSL behavior;
* preserve existing registry-based resolver lookup;
* support ordering or precedence when multiple resolvers are available;
* allow custom YAML steps to contain nested steps when the target model
definition supports them;
* avoid hard-coding component-specific step names in the YAML DSL module.
h3. Acceptance criteria:
* A test or sample optional module can provide a custom YAML route step
deserializer.
* The custom YAML step is discovered automatically when the module is
available.
* The custom YAML step can be parsed into a Camel route model definition.
* Nested YAML {{steps}} are supported when the custom model definition
supports child outputs.
* Existing YAML routes and built-in EIPs continue to parse unchanged.
* Resolver ordering/precedence is deterministic.
* The extension mechanism is documented for component authors.
was:
Camel YAML DSL currently supports built-in route model deserializers and custom
resolvers registered in the Camel registry. However, optional Camel modules do
not have a simple generic way to contribute YAML route step deserializers
automatically when the module is present on the classpath.
This makes it difficult for an optional module to expose a custom YAML route
step without requiring changes in the YAML DSL module itself or requiring users
to manually register YAML resolver beans before route parsing.
This improvement proposes adding a YAML-only extension point that allows
optional modules to provide YAML route step deserializers in a discoverable way.
The goal is to let an optional module contribute support for a custom YAML step
name, map that YAML node to a Camel route model definition, and then rely on
the existing model/reifier/ProcessorFactory mechanisms for runtime behavior.
The implementation should:
* allow optional modules to contribute {{YamlDeserializerResolver}}
implementations;
* discover those resolvers before YAML routes are parsed;
* preserve the existing built-in YAML DSL behavior;
* preserve existing registry-based resolver lookup;
* support ordering or precedence when multiple resolvers are available;
* allow custom YAML steps to contain nested steps when the target model
definition supports them;
* avoid hard-coding component-specific step names in the YAML DSL module.
Acceptance criteria:
* A test or sample optional module can provide a custom YAML route step
deserializer.
* The custom YAML step is discovered automatically when the module is
available.
* The custom YAML step can be parsed into a Camel route model definition.
* Nested YAML {{steps}} are supported when the custom model definition
supports child outputs.
* Existing YAML routes and built-in EIPs continue to parse unchanged.
* Resolver ordering/precedence is deterministic.
* The extension mechanism is documented for component authors.
> Add YAML DSL extension point for component-provided route step deserializers
> ----------------------------------------------------------------------------
>
> Key: CAMEL-23775
> URL: https://issues.apache.org/jira/browse/CAMEL-23775
> Project: Camel
> Issue Type: Improvement
> Components: dsl
> Reporter: Luigi De Masi
> Assignee: Luigi De Masi
> Priority: Major
>
> Camel YAML DSL currently supports built-in route model deserializers and
> custom resolvers registered in the Camel registry. However, optional Camel
> modules do not have a simple generic way to contribute YAML route step
> deserializers automatically when the module is present on the classpath.
> This makes it difficult for an optional module to expose a custom YAML route
> step without requiring changes in the YAML DSL module itself or requiring
> users to manually register YAML resolver beans before route parsing.
> This improvement proposes adding a YAML-only extension point that allows
> optional modules to provide YAML route step deserializers in a discoverable
> way.
> The goal is to let an optional module contribute support for a custom YAML
> step name, map that YAML node to a Camel route model definition, and then
> rely on the existing model/reifier/ProcessorFactory mechanisms for runtime
> behavior.
> h3. The implementation should:
> * allow optional modules to contribute {{YamlDeserializerResolver}}
> implementations;
> * discover those resolvers before YAML routes are parsed;
> * preserve the existing built-in YAML DSL behavior;
> * preserve existing registry-based resolver lookup;
> * support ordering or precedence when multiple resolvers are available;
> * allow custom YAML steps to contain nested steps when the target model
> definition supports them;
> * avoid hard-coding component-specific step names in the YAML DSL module.
>
> h3. Acceptance criteria:
> * A test or sample optional module can provide a custom YAML route step
> deserializer.
> * The custom YAML step is discovered automatically when the module is
> available.
> * The custom YAML step can be parsed into a Camel route model definition.
> * Nested YAML {{steps}} are supported when the custom model definition
> supports child outputs.
> * Existing YAML routes and built-in EIPs continue to parse unchanged.
> * Resolver ordering/precedence is deterministic.
> * The extension mechanism is documented for component authors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
