[
https://issues.apache.org/jira/browse/CAMEL-23779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-23779:
----------------------------------
Description:
Camel YAML DSL currently exposes `YamlDeserializerResolver` as the extension
hook for contributing custom YAML deserialization behavior. Its contract
returns SnakeYAML's `ConstructNode` directly, which means extension authors
need to depend on Camel's current SnakeYAML construction flow and parser-level
internals.
This works for advanced internal usage, but it makes the public extension
surface harder to implement, document, and evolve. If Camel changes YAML parser
internals, upgrades SnakeYAML in a breaking way, or wants to support additional
YAML extension points, external modules using this SPI may be unnecessarily
coupled to those details.
The goal of this task is to design a Camel-owned YAML deserialization SPI that
lets optional modules contribute custom YAML DSL behavior without implementing
SnakeYAML `ConstructNode` directly.
Initial scope can focus on custom route step deserialization, but the design
should be general enough to support future YAML DSL extension points such as
custom model definitions, output-aware/block definitions, or other YAML model
fragments.
h3. Proposed scope
* Introduce a Camel-owned abstraction for YAML DSL deserialization extensions.
* Provide a first implementation path for custom route step names mapped to
Camel route model definitions.
* Support nested `steps` where the target model definition can contain outputs.
* Keep existing `YamlDeserializerResolver` support for backward compatibility.
* Provide an adapter from the new SPI to the existing internal
resolver/deserializer flow.
* Define deterministic precedence when built-in resolvers, existing
`YamlDeserializerResolver` providers, and new SPI providers are all present.
* Avoid exposing SnakeYAML parser/construction types in the new public
extension contract.
* Document migration guidance and examples for extension authors.
* Add tests covering parsing, nested steps, ordering, registry/classpath
discovery, and compatibility with existing resolvers.
h3. Acceptance criteria
* Optional modules can contribute YAML DSL deserialization behavior without
directly implementing SnakeYAML `ConstructNode`.
* The first supported use case covers custom YAML route step names mapped to
Camel model definitions.
* Existing `YamlDeserializerResolver` implementations continue to work
unchanged.
* Built-in YAML DSL behavior remains unchanged.
* Precedence between built-in resolvers, existing resolver providers, and new
SPI providers is deterministic and documented.
* Component-author documentation includes examples using the new Camel-owned
SPI.
> YAML DSL: Add Camel-owned deserialization SPI decoupled from SnakeYAML
> internals
> --------------------------------------------------------------------------------
>
> Key: CAMEL-23779
> URL: https://issues.apache.org/jira/browse/CAMEL-23779
> Project: Camel
> Issue Type: Improvement
> Reporter: Luigi De Masi
> Priority: Minor
>
> Camel YAML DSL currently exposes `YamlDeserializerResolver` as the extension
> hook for contributing custom YAML deserialization behavior. Its contract
> returns SnakeYAML's `ConstructNode` directly, which means extension authors
> need to depend on Camel's current SnakeYAML construction flow and
> parser-level internals.
> This works for advanced internal usage, but it makes the public extension
> surface harder to implement, document, and evolve. If Camel changes YAML
> parser internals, upgrades SnakeYAML in a breaking way, or wants to support
> additional YAML extension points, external modules using this SPI may be
> unnecessarily coupled to those details.
> The goal of this task is to design a Camel-owned YAML deserialization SPI
> that lets optional modules contribute custom YAML DSL behavior without
> implementing SnakeYAML `ConstructNode` directly.
> Initial scope can focus on custom route step deserialization, but the design
> should be general enough to support future YAML DSL extension points such as
> custom model definitions, output-aware/block definitions, or other YAML model
> fragments.
> h3. Proposed scope
> * Introduce a Camel-owned abstraction for YAML DSL deserialization
> extensions.
> * Provide a first implementation path for custom route step names mapped to
> Camel route model definitions.
> * Support nested `steps` where the target model definition can contain
> outputs.
> * Keep existing `YamlDeserializerResolver` support for backward
> compatibility.
> * Provide an adapter from the new SPI to the existing internal
> resolver/deserializer flow.
> * Define deterministic precedence when built-in resolvers, existing
> `YamlDeserializerResolver` providers, and new SPI providers are all present.
> * Avoid exposing SnakeYAML parser/construction types in the new public
> extension contract.
> * Document migration guidance and examples for extension authors.
> * Add tests covering parsing, nested steps, ordering, registry/classpath
> discovery, and compatibility with existing resolvers.
> h3. Acceptance criteria
> * Optional modules can contribute YAML DSL deserialization behavior without
> directly implementing SnakeYAML `ConstructNode`.
> * The first supported use case covers custom YAML route step names mapped to
> Camel model definitions.
> * Existing `YamlDeserializerResolver` implementations continue to work
> unchanged.
> * Built-in YAML DSL behavior remains unchanged.
> * Precedence between built-in resolvers, existing resolver providers, and
> new SPI providers is deterministic and documented.
> * Component-author documentation includes examples using the new Camel-owned
> SPI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
