[
https://issues.apache.org/jira/browse/CAMEL-23775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi closed CAMEL-23775.
---------------------------------
Fix Version/s: 4.21.0
Resolution: Fixed
> 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
> Fix For: 4.21.0
>
>
> 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)
