You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Luigi De Masi (Jira)" <ji...@apache.org> on 2026/06/17 05:36:00 UTC

[jira] [Created] (CAMEL-23779) YAML DSL: Add Camel-owned deserialization SPI decoupled from SnakeYAML internals

Luigi De Masi created CAMEL-23779:
-------------------------------------

             Summary: 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
         Environment: 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.
            Reporter: Luigi De Masi






--
This message was sent by Atlassian Jira
(v8.20.10#820010)