[
https://issues.apache.org/jira/browse/CAMEL-24915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118328#comment-18118328
]
Claus Ibsen commented on CAMEL-24915:
-------------------------------------
h3. How often is {{handled}} actually dynamic
Counted across the checkouts on hand - camel, camel-quarkus, camel-spring-boot,
camel-karaf, camel-examples, camel-kamelets - by whether the value is a
constant {{true}}/{{false}} or a real predicate:
|| source || constant || dynamic ||
| documentation | 89 | 0 |
| src/main | 20 | 2 |
| src/test | 513 | 2 |
| *total* | *622* | *4* |
By repository: camel 591/2, camel-quarkus 20/2, camel-spring-boot 5/0,
camel-karaf 4/0, camel-examples 2/0.
All four dynamic uses:
* {{OnExceptionHandledThrowsExceptionTest}} - a lambda that throws, to test
what happens when the predicate itself fails
* {{ExceptionBuilderWithHandledExceptionTest}} - {{header("foo")...}}, a test
of the predicate form itself
* {{MdcLogRoutes}} in camel-quarkus (twice) - a lambda that logs MDC values and
returns true, which is a side effect in a predicate rather than a decision
So of the four, two exist to test the predicate form, and two use it for a side
effect rather than for a condition. Not one of them decides {{handled}} from
the message.
h3. What the data is and is not
This is what is in the source of the projects, and it is weighted towards
tests: 513 of the 622 constants are in {{src/test}}. Routes people write in
their own systems are not visible here, so this does not prove the dynamic form
is unused in the field - someone may well have a good reason for it. What it
does show is that inside Camel itself, its examples and three of its runtimes,
the dynamic form is used four times and never for the thing it was designed for.
That is the trade the shortcut is weighed against: 622 uses that have to write
the long form, to keep a shape that four uses need.
> 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)
