[
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 and
runtime integrations do not have a generic Camel-owned way to contribute or
control YAML route step deserializer discovery before YAML routes are parsed.
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 early enough before route parsing.
It also makes runtime integration less flexible, because resolver discovery
is tied to runtime classpath scanning. Some runtimes may prefer to provide
resolver metadata through their own mechanism, for example build-time discovery
or precomputed resolver registration.
This improvement adds a YAML DSL extension SPI for route step deserializers.
The goal is to let optional modules contribute support for custom YAML step
names, map those YAML nodes to Camel route model definitions, and then rely on
the existing model/reifier/ProcessorFactory mechanisms for runtime behavior.
The extension mechanism should also allow runtimes to replace or customize
resolver discovery while preserving the default classpath-based behavior for
plain Camel usage.
h3. The implementation should:
* allow optional modules to contribute {{YamlDeserializerResolver}}
implementations;
* discover those resolvers before YAML routes are parsed;
* provide a Camel-owned provider SPI for resolver discovery;
* preserve the default classpath-based resolver discovery behavior;
* allow runtimes to replace or customize resolver discovery through the
Camel context plugin mechanism;
* preserve existing registry-based resolver lookup;
* support deterministic 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.
* Existing registry-based resolver discovery continues to work.
* Resolver ordering/precedence is deterministic.
* Runtime integrations can provide their own resolver discovery provider.
* The default implementation preserves existing classpath-based discovery.
* The extension mechanism is documented for component authors and runtime
integrations.
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.
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.
> 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 and runtime integrations do not have a generic Camel-owned way to
> contribute or control YAML route step deserializer discovery before YAML
> routes are parsed.
> 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 early enough before
> route parsing.
> It also makes runtime integration less flexible, because resolver discovery
> is tied to runtime classpath scanning. Some runtimes may prefer to provide
> resolver metadata through their own mechanism, for example build-time
> discovery or precomputed resolver registration.
> This improvement adds a YAML DSL extension SPI for route step deserializers.
> The goal is to let optional modules contribute support for custom YAML step
> names, map those YAML nodes to Camel route model definitions, and then rely
> on the existing model/reifier/ProcessorFactory mechanisms for runtime
> behavior.
> The extension mechanism should also allow runtimes to replace or customize
> resolver discovery while preserving the default classpath-based behavior for
> plain Camel usage.
> h3. The implementation should:
> * allow optional modules to contribute {{YamlDeserializerResolver}}
> implementations;
> * discover those resolvers before YAML routes are parsed;
> * provide a Camel-owned provider SPI for resolver discovery;
> * preserve the default classpath-based resolver discovery behavior;
> * allow runtimes to replace or customize resolver discovery through the
> Camel context plugin mechanism;
> * preserve existing registry-based resolver lookup;
> * support deterministic 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.
> * Existing registry-based resolver discovery continues to work.
> * Resolver ordering/precedence is deterministic.
> * Runtime integrations can provide their own resolver discovery provider.
> * The default implementation preserves existing classpath-based discovery.
> * The extension mechanism is documented for component authors and runtime
> integrations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
