[davsclaus]

Stacked on #28314. This group covers the components most used in the example routes that still had no catalog body types (CAMEL-24961): as2, jdbc (and spring-jdbc, whose endpoint extends it), smooks, vertx-http, tika, snmp, pdf, file-watch, scp, graphql and micrometer.

What the catalog says now

Component	Consumer	Producer input	Producer output
as2	server/listen: the EDI message as text, or a stream with the base64 or binary transfer encoding; receipt/receive: the receipt (MDN) entity	any, not known when inBody is set: with inBody=ediMessage the EDI message, text or a stream	the receipt entity when dispositionNotificationTo asks for one, else no body
jdbc, spring-jdbc		the SQL statement as text, bytes, a stream or a file	a select: a List of Maps; SelectOne: the Map, the value of its one column, or no body; StreamList: an iterator; unchanged for a statement that is not a select
smooks		text, bytes, a stream or a file	unknown: what the exports of the Smooks config give
vertx-http		no body, text, bytes, a stream or a file	bytes, or no body
tika		text, bytes, a stream or a file	parse: bytes, the content in a ByteArrayOutputStream; detect: the media type as text
snmp	the PDU as XML text	any; an SNMP4J PDU for TRAP	POLL: an SnmpMessage; GET_NEXT: a List of them; TRAP: unchanged
pdf		create and append: text, bytes, a stream or a file; extractText: the PDF as bytes, a stream, a file or a PDDocument; merge: any	create, append and merge: bytes, the PDF in a ByteArrayOutputStream; extractText: text
file-watch	the java.io.File of the event
scp		text, bytes, a stream or a file; also no body with allowNullBody	unchanged
graphql		the query as text, bytes, a stream or a file, when none of query, queryFile and queryHeader is set	the response as text, or no body
micrometer		any	unchanged

Checked at runtime. Routes run with camel run logged the class of the body after each step, with text, bytes, streams, files, Maps, Lists, POJOs and no body. Local servers where needed: an H2 data source, a fake HTTP server, an SSH server with scp (Apache MINA SSHD), an SNMP agent (SNMP4J), and the as2 server and receipt consumer of the component itself.

• as2:
  • client/send takes text or a stream; bytes, a file and a Map fail with "Failed to create EDI message entity";
  • the body after the send is the receipt with a synchronous MDN, and no body without one or with an asynchronous one;
  • server/listen gives the EDI message as text, or a stream with the base64 or binary transfer encoding;
  • receipt/receive gives a DispositionNotificationMultipartReportEntity.
• jdbc:
  • text, bytes, a stream and a file all run as SQL; a Map and a List are sent as their toString(), which fails;
  • a select gives a List of LinkedHashMap rows;
  • SelectOne gives the Map, the value of a one-column row (a String, a Long, a byte[] or a Blob), or null, and fails for two rows;
  • StreamList gives a StreamListIterator; an update, an insert and DDL keep the body.
• smooks: text, bytes, a stream and a file are read; a POJO (not wrapped in a JavaSource), a Map, a List and no body fail. The output is the extracted bean of a JavaSink, the bean Map without extract, the text of a StringSink, and a stream of the input without exports.
• vertx-http:
  • text, bytes, a stream, a file and no body are sent; a Map, a List, a POJO, a number and a Path fail;
  • the response is a byte[] whatever its size, and null for a 204.
• tika:
  • text, bytes, a stream and a file are read; a Map, a List, a POJO and no body fail;
  • parse gives a ByteArrayOutputStream of XHTML, HTML or text; detect gives the media type as a String.
• snmp:
  • the poll and trap consumers give the XML text of the PDU;
  • the trap producer sends a PDU body and keeps it, and a text body fails;
  • the POLL producer gives an SnmpMessage, GET_NEXT a List of them.
• pdf:
  • create and append write the body as text;
  • extractText reads bytes, a stream or a file, but not the ByteArrayOutputStream that create leaves (convert it to bytes first) and not text;
  • merge takes its files from a header.
• file-watch: the body is a java.io.File for CREATE, MODIFY and DELETE events, and for directories too.
• scp: text, bytes, a stream and a file are stored; a Map, a List and a POJO fail; no body fails unless allowNullBody=true.
• graphql:
  • with the query option the body is not sent, except a camel-util-json JsonObject, which is the variables;
  • without it the body is the query;
  • the response is a String, with GraphQL errors inside a 200 not failing the exchange.
• micrometer: counters, summaries and timers keep the body, whatever it is.

Choices

• The ByteArrayOutputStream that tika parse and pdf create, append and merge leave is bytes, with that class as its javaType (second commit, after a review question): it holds the bytes of the PDF or of the parsed content and converts to a byte array, so a field read after it is reported as after any bytes.
• as2 producerIn is any, and not known when inBody is set, as for fhir (third commit, after a review question): inBody can name any of the 23 arguments of client/send, and the EDI message is text or a stream only because of CAMEL-26052, which is a bug rather than a rule to check.
• graphql producerIn depends on query, queryFile and queryHeader: the body is checked only when it is the query.
• vertx-http responsePayloadAsByteArray is also a component option, so it is only in the description: naming it would make the output side unknown for every step that leaves it out.
• spring-jdbc has the same body types as jdbc: its endpoint extends JdbcEndpoint, and body types are not inherited.

Bugs found and filed, one per component:

• CAMEL-26052 (Major), as2: client/send sends only text or a stream, so the file of a file consumer fails; an HTTP error of the partner does not fail the exchange; the default of requestUri does not apply; ediMessageType is not read; quoted-printable sends base64; the server logs an ERROR for every unencrypted message.
• CAMEL-26053 (Major), graphql: the Content-Type and Accept headers of the message replace application/json on the request, the query header is sent as an HTTP header, and CamelHttpMethod=post stays on the message after the call (since CAMEL-22562); a Map body is sent as its toString() as the query.
• CAMEL-26054 (Major), pdf: the pageSize values of the catalog are ignored (A4 gives a Letter page); pdf:create followed by pdf:extractText fails; a CR or a tab fails with the default lineTermination.
• CAMEL-26055, snmp: the producer without type sends no OIDs; the trap producer fails with a NullPointerException for a body that is not a PDU; GET_NEXT fails on a consumer; the SnmpMessage body of the producer does not convert to text.
• CAMEL-26056, jdbc: an outputClass that does not resolve fails with a NullPointerException; generated keys are mapped to outputClass; a Blob cannot be read after the producer; a null body fails with a NullPointerException.
• CAMEL-26057, tika: a body that does not convert to a stream fails with a NullPointerException; the output encoding is lost when the output converts to text.
• CAMEL-26058, vertx-http: a Path body fails; a urlencoded form keeps its escapes.
• CAMEL-26059, scp: a NullPointerException without a known hosts file; the remote directory must exist.
• CAMEL-26060, file-watch: CamelFileLastModified is the time of the event, not of the file.
• CAMEL-26061, micrometer: the docs say a warning is logged where the exchange fails.
• CAMEL-26062, smooks: SAXSource, remote file and File bodies fail with a reader in the config (read in the code).

Docs fixed (the prose about the body only):

• jdbc: the rows are LinkedHashMaps of a select; what SelectOne and StreamList give; another statement keeps the body.
• graphql: the query comes from the body when no query option is set, and only a camel-util-json JsonObject is the variables.
• tika: what the body is before and after detect and parse, and that other types need their Tika parser module.
• pdf: convert the output of create to bytes before extractText.
• smooks: a POJO is read from a JavaSource body.
• snmp: what the POLL, GET_NEXT and TRAP producers give, and the XML example without the declaration the code does not write.

Measured.

• The validator over the 1204 human-written and 1209 model-written route files gives the same reports as with CAMEL-24961: Catalog body types for eleven more AWS components #28314.
• Body types now cover 97.5% of the endpoint uses in the human-written routes (96.6% with CAMEL-24961: Catalog body types for eleven more AWS components #28314), and 139 of the 413 component JSONs have them.

Tests

• TextBodyFlowTest.testTheBodyOfQueriesDocumentsAndFiles:
  • reported: a Map sent to jdbc, scp, vertx-http, tika parse, pdf create, and graphql without a query option; a field read after graphql, tika detect, pdf extractText, the as2 server and the snmp trap consumer;
  • not reported: a Map sent to graphql with a query, and a field read after jdbc, micrometer (the body is kept) and smooks.
• CatalogDocsTest uses ldif instead of jdbc as the component without body types.
• These pass:
  • the 293 tests of camel-yaml-dsl-validator;
  • the 265 validator and catalog doc tests of camel-jbang-core;
  • the builds of camel-yaml-dsl-maven-plugin and camel-yaml-dsl-deserializers.
• The answers of camel_catalog_doc stay under 18 000 characters: vertx-http, the largest, is 13 148.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code