[davsclaus]

Stacked on #28302. This is the second messaging group of the catalog body types (CAMEL-24961):

• the mail component (imap, imaps, pop3, pop3s, smtp and smtps);
• paho, spring-rabbitmq, pulsar and nats;
• smpp (smpp and smpps).

What the catalog says now

Component	Consumer	Producer input	Producer output
mail	a String for text/plain, text/html and text/xml, a stream for another content type, a Multipart for a multipart mail (attachments in the attachments); the jakarta.mail.Message with mapMailMessage=false	text, bytes, a stream or a file, read as text, or no body; a MimeMessage is sent as it is	unchanged
paho	bytes	text, bytes, stream or file	unchanged
spring-rabbitmq	a String for a text content type, bytes otherwise	text, bytes, stream or file; no body with allowNullBody	unchanged for InOnly; the reply for InOut
pulsar	bytes	text, bytes, stream or file; other bodies go through Java serialization	unchanged
nats	bytes; the reply only with exchangePattern=InOut	text, bytes, stream or file	unchanged for InOnly; the reply as bytes for InOut
smpp	the short message as text, or bytes for an 8-bit data coding; no body for data_sm and alerts	text, bytes or file, read as text	unchanged for InOnly; no body for InOut

The sides of spring-rabbitmq depend on its messageConverter, as those of jms do, so the validator says nothing for them unless the endpoint sets one.

Checked at runtime. Routes run with camel run logged the class of the body after each step:

• mail against GreenMail embedded through a bean;
• paho, spring-rabbitmq, pulsar and nats against camel infra run mosquitto, rabbitmq, pulsar and nats;
• smpp against the jSMPP simulator of the camel-smpp integration test.

What the runs showed:

• mail:
  • the consumer gives the bodies above for plain, HTML, alternative, mixed, attachment-only, binary, PDF and Latin-1 mails;
  • the producer sends bytes, a stream or a file as their text, a Map as its toString(), no body as an empty text, and a MimeMessage with its own subject.
  • With GreenMail, imap failed on every multipart mail ("Unable to load BODYSTRUCTURE"), so the multipart cases were read with pop3. Both protocols share MailBinding.
• paho and paho-mqtt5:
  • text, bytes, a stream and a file are sent;
  • a Map, a POJO, a number or no body fail with a NullPointerException.
• spring-rabbitmq:
  • a text body arrives as a String, anything else as bytes;
  • a Map or a Serializable POJO fails, as it is not serialized;
  • a reply that is a Map fails, and the listener runs the route five times.
• pulsar: a Map, a List, a Serializable POJO, a number and no body are sent with Java serialization.
• nats:
  • a Map is sent as its toString();
  • a consumer replies only with exchangePattern=InOut, and the reply arrives as bytes.
• smpp:
  • a submit_sm leaves the body as it was, with the ids in CamelSmppId;
  • a deliver_sm and a delivery receipt arrive as text;
  • an InOut send leaves no body.

Bugs found and filed, one per component:

• CAMEL-26013 (Major), mail:
  • one multipart mail with no text part makes every later multipart mail convert to MimeMultipart@... text, as the type converter keeps the fallback;
  • text without a charset in contentType is sent in the JVM charset but labelled without one;
  • a text/csv first part converts to the name of a stream;
  • a producer on imap or pop3 fails each send with "invalid provider";
  • a mail read with mapMailMessage=false cannot be forwarded;
  • setting the body to null in a processor gives back the mail.
• CAMEL-26014 (Major), smpp:
  • a stream body is sent as an empty short message, and no body fails with a NullPointerException;
  • the 8-bit dataCoding and alphabet endpoint options do not send bytes as they are, only the headers do;
  • an InOut send loses the body and the headers;
  • a misspelled CamelSmppCommand sends an SMS.
• CAMEL-26015 (Major), spring-rabbitmq:
  • a reply, or a forwarded message, keeps the content type of the consumed message, so bytes arrive as a String;
  • a reply that is a Spring AMQP Message has no correlation id.
• CAMEL-26016, nats:
  • a reply that does not convert to bytes is dropped silently;
  • a JetStream consumer with exchangePattern=InOut publishes its reply to the ack subject.
• CAMEL-26017, paho and paho-mqtt5: a body that does not convert to bytes fails with a NullPointerException with no message.
• CAMEL-26012 (Improvement), pulsar: turn off the Java serialization of bodies that do not convert to bytes, and deprecate it.
• CAMEL-26018: the CamelMailAlternativeBody header is not in the catalog, so the validator rejects a route that sets it. It is fixed in its own PR.

Docs fixed:

• nats: the consumer replies only with exchangePattern=InOut, and the producer gets the reply as a byte array.
• mail:
  • the producer reads the body as text and sends a MimeMessage as it is;
  • a split of the attachments gives their content as the body; the snippet used a constructor removed in 2019.
• smpp:
  • an 8-bit data coding or alphabet header sends bytes as they are;
  • the component does not detect the encoding;
  • text in ISO-8859-1 is split by 140 bytes only with the 8-bit alphabet;
  • the CamelSmppEncoding header is the charset of the text; the endpoint DSL holds a copy of its description, so SmppEndpointBuilderFactory is regenerated (second commit).

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 the binary data formats #28302.
• Body types now cover 94.8% of the endpoint uses in the human-written routes (93.9% with CAMEL-24961: Catalog body types for the binary data formats #28302).

Tests

• TextBodyFlowTest.testTheBodyOfMessaging:
  • reported: a field read after the paho consumer, parsed data sent to pulsar and to smtp, and parsed data as the reply of a nats consumer with exchangePattern=InOut;
  • not reported: a nats consumer without InOut, spring-rabbitmq, and a field read after imap.
• These pass:
  • the 289 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: spring-rabbitmq, the largest, is 17 577.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet-bot]

Previous findings are all addressed. LGTM.

The new commit (5139879b) regenerates SmppEndpointBuilderFactory.java to sync the CamelSmppEncoding header description with SmppConstants.java (scope DataSm → ReplaceSm, description rewrite) — a generated artifact update with no new issues. All @BodyTypes annotations match runtime behavior, JSON catalog entries are consistent with the annotations, doc corrections are accurate, and the new testTheBodyOfMessaging test covers the right 4 validator conditions.

This review was generated by an AI agent, Hermès on behalf of @gnodet.