[
https://issues.apache.org/jira/browse/CAMEL-24915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118330#comment-18118330
]
Claus Ibsen commented on CAMEL-24915:
-------------------------------------
h3. A split instead of a shortcut
Raised by [~davsclaus]: keep {{handled}} for the boolean and add
{{handledWhen}} for the expression, rather than teaching the DSL to accept two
shapes for one property.
What that costs, checked against the code:
* *Java: nothing.* {{OnExceptionDefinition}} already has all three overloads -
{{handled(boolean)}}, {{handled(Predicate)}} and {{handled(Expression)}}.
{{.handled(true)}} keeps working untouched, and the two predicate overloads can
set the new field internally, so no Java route changes and no deprecation is
forced on anyone.
* *XML and YAML migrate*, and that is everyone who writes them. Both migrations
are mechanical - {{<handled><constant>true</constant></handled>}} to
{{handled="true"}}, and {{handled: {constant: {expression: "true"}}}} to
{{handled: true}} - which is what {{camel-upgrade-recipes}} and {{camel
update}} exist for. With 622 constants and 4 predicates in the source we have,
a recipe covers all but a handful, and the handful is visible in review.
h3. Why it reads this way today
It was a Java-first API 15+ years ago, where {{.handled(true)}} is the natural
call and the expression overload costs nothing to offer. XML then had to spell
the same thing as {{<handled><constant>true</constant></handled>}}, and the
count says XML never used the flexibility it was paying for: 73 constants, 0
predicates.
h3. What cannot be done
{{handled}} defaulting to true, which is the other thing the numbers suggest. A
route with an {{onException}} and no {{handled}} today lets the exception
propagate; flipping the default would silently swallow exceptions in every such
route. A shape change is reviewable, a default change is not.
h3. The cheaper path, if the split is too much for 4.x
Accept the boolean shape additively (this issue as originally filed) *and* add
{{handledWhen}} as the way to write the predicate, deprecating the expression
form of {{handled}} without removing it. Nothing has to migrate, the short form
becomes idiomatic immediately, and 5.x can drop the long form once the
migration recipe has been available for a release or two.
> camel-yaml-dsl: accept a plain value for handled and the other expression
> sub-elements as a constant
> ----------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24915
> URL: https://issues.apache.org/jira/browse/CAMEL-24915
> Project: Camel
> Issue Type: Improvement
> Components: camel-yaml-dsl
> Reporter: Claus Ibsen
> Priority: Minor
>
> In the local-model benchmark (s11: 5 runs of four HTTP rungs) the single most
> common validation failure was `handled: true` under `onException`:
> {code:yaml}
> - onException:
> exception:
> - org.apache.camel.http.base.HttpOperationFailedException
> handled: true
> ...
> {code}
> The YAML DSL refuses it, because `handled` is an
> `ExpressionSubElementDefinition` and requires an expression:
> {noformat}
> handled: a plain value (true) found, an expression expected: write handled:
> {constant: {expression: "true"}}
> {noformat}
> It happened 9 times across 20 runs, and it is what a human writes too - the
> Java DSL is `.handled(true)`.
> Proposal: when an expression sub-element (`handled`, `continued`,
> `retryWhile`, `completionPredicate`, ...) is given a plain scalar, read it as
> a constant expression, the same value the long form produces. The refusal
> message already says that is what the long form means, so there is no other
> sensible reading of a scalar there.
> Touches the generated `ExpressionSubElementDefinitionDeserializers` (so the
> generator, not the generated file) and the JSON schema, which must allow a
> scalar next to the object form.
> Evidence: the s11 traces under the AI route benchmark; see also CAMEL-24886.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
