Claus Ibsen created CAMEL-25928:
-----------------------------------
Summary: camel-catalog - the body types of the EIPs: the body
after each EIP and the body its own steps start with
Key: CAMEL-25928
URL: https://issues.apache.org/jira/browse/CAMEL-25928
Project: Camel
Issue Type: Improvement
Components: camel-catalog, camel-core
Reporter: Claus Ibsen
Fix For: 4.24.0
The EIP part of CAMEL-24961 (phase C of CAMEL-24844). CAMEL-24961 adds
{{@BodyTypes}} and a {{bodyTypes}} section in the catalog JSON for the
components, data formats and languages
(https://github.com/apache/camel/pull/28241 and
https://github.com/apache/camel/pull/28242). The EIPs have none yet. So the
YAML validator keeps its own EIP tables, and {{camel_catalog_doc}} cannot say
what the body is after a {{split}} or a {{convertBodyTo}}.
h3. What the EIPs do with the body
The steps of the YAML routes in camel-jbang-examples, camel-examples and
camel-kamelets use 38 EIPs: 4278 uses in 1107 files. The 20 EIPs in this table
have 98.5% of them:
||EIP||uses||the body after it||
|to|1244|the endpoint's producerOut (CAMEL-24961)|
|setHeader|1084|unchanged|
|choice|408|its branches start with the same body; after it, what the branch
that ran ends with|
|log|240|unchanged|
|marshal|203|the data format's marshalOut|
|setBody|193|the language's expressionOut|
|setProperty|193|unchanged|
|removeHeader|150|unchanged|
|unmarshal|141|the data format's unmarshalOut|
|convertBodyTo|56|the type that its type option names; null with
mandatory=false when there is no conversion (ConvertBodyProcessor.java:149-152)|
|bean|44|the method's return value; unchanged for a void method
(MethodInfo.java:337)|
|process|42|unknown: the user's code|
|setVariable|41|unchanged|
|toD|31|the producerOut of the endpoint's scheme|
|filter|29|its steps start with the same body; unchanged when it does not match|
|removeHeaders|28|unchanged|
|split|26|its steps get each part; after it, the body before the split, unless
aggregationStrategy is set (UseOriginalAggregationStrategy,
Splitter.java:193-194)|
|script|24|unchanged: the EIP does not use the result
(ScriptProcessor.java:46), but the script can set the body|
|stop|22|unchanged: the route ends|
|transform|15|the language's expressionOut|
The EIPs fall into three groups:
# *They keep the body*: setHeader, setHeaders, setProperty, setVariable,
setVariables, removeHeader(s), removeProperty(ies), removeVariable,
convertHeaderTo, convertVariableTo, log, validate, delay, throttle, sample,
wireTap, stop. Each is a fact the catalog can state: {{unchanged}}.
# *Their body comes from another model of the catalog*: the language (setBody,
transform), the data format (marshal, unmarshal), the endpoint (to, toD,
enrich; the consumer side for pollEnrich and poll), or their own steps (choice,
filter, doTry, step, circuitBreaker). Their body types are the ones CAMEL-24961
adds, so they need a reference, not a copy.
# *They have their own rule*:
#* split, as above;
#* multicast and recipientList: the last reply, unless aggregationStrategy is
set (UseLatestAggregationStrategy: MulticastReifier.java:125-127,
RecipientListReifier.java:151-153);
#* aggregate: what its aggregationStrategy makes;
#* loop: the body of the last iteration (LoopProcessor.java:168);
#* sort: a List (SortProcessor.java:50-53);
#* claimCheck: unchanged for Set and Push; the stored body for Get,
GetAndRemove and Pop (ClaimCheckAggregationStrategy.java:67-69);
#* enrich and pollEnrich: the resource's reply with the default strategy
(Enricher.java:314, PollEnricher.java:618-619). pollEnrich gives null after a
timeout (PollEnricher.java:719);
#* convertBodyTo, as above.
The table and the groups are read from the code on main and not yet checked at
runtime.
h3. Proposed shape
* {{@BodyTypes}} goes on the EIP model classes of camel-core-model, such as
{{SplitDefinition}}. {{SchemaGeneratorMojo}} reads it: it loads the model
class, as {{EndpointSchemaGeneratorMojo}} does the endpoint class.
{{BodyTypesHelper}} checks it, and it goes into the {{bodyTypes}} section of
the {{models/*.json}} files.
* {{JsonMapper}} reads and writes it for {{EipModel}}. {{camel_catalog_doc}}
then returns it with no change of its own, since {{addCommonModelFields}} is
shared with the EIPs.
* The sides for the eip kind:
** {{eipIn}}: the bodies the EIP needs (sort needs a List);
** {{eipOut}}: the body after it;
** {{eipSteps}}: the body that its own steps start with. That is each part for
split, each iteration for loop, the aggregated body for aggregate, and the same
body for choice and filter.
* {{dependsOn = "aggregationStrategy"}} for split, multicast and recipientList:
the default strategy's body holds until a strategy is set.
h3. Open decisions
# *Group 2*: point to the other model in the metadata, for example {{from =
"expression"}}, {{"dataFormat"}}, {{"endpoint"}} or {{"steps"}}. Or leave group
2 to the validator's walk, which already follows the language, the data format,
the endpoint and the nested steps, and declare groups 1 and 3 only.
# *variableReceive*: with it, the result goes into the variable and the body
stays as it was (MarshalProcessor.java:94-95, PollEnricher.java:436-440). to,
toD, enrich, pollEnrich, poll, marshal and unmarshal have the option. The
{{byOption}} of {{@BodyType}} needs an exact value today, so it needs a form
for "set to any value".
# *convertBodyTo*: its body is the Java type that an option value names. Either
a {{byOption}} for each common type (String, byte[], InputStream, Map), or a
new member that names the option that holds the type.
h3. How it is checked
As for the components:
* The message history records the body type at each node (CAMEL-25750). A
reference route for each EIP, run with message history on, gives the body after
the EIP (at the next step) and in its steps (at the first nested step).
* camel-core's tests use {{ContextTestSupport}}, which does not dump the route
coverage. So the reference routes run in a camel-main harness, as for timer and
xslt in CAMEL-24961.
* The YAML examples of the EIP pages, which {{EipDocExamplesTest}} validates in
the build, are a starting set of reference routes.
h3. What it unlocks
* The EIP tables of {{TextBodyFlow}} in camel-yaml-dsl-validator move into the
catalog:
** {{KEEPING_STEPS}}: group 1;
** {{SAME_BODY_BLOCKS}}: choice, when, otherwise, filter, doTry, doCatch,
doFinally.
* The EIP pages and {{camel_catalog_doc}} say what the body is after each EIP,
as the component pages will.
h3. First slice
The EIPs of the table except {{to}}, whose body types are the components'. Then
the other 62 EIPs of the catalog.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
