davsclaus opened a new pull request, #28306:
URL: https://github.com/apache/camel/pull/28306
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 (to file):**
- mail:
- one multipart mail with no text part makes every later multipart mail
convert to `MimeMultipart@...` text, as the type converter keeps the fallback
(Major);
- text without a charset in contentType is sent in the JVM charset but
labelled without one, so "Grüße" arrives garbled;
- 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 ("POP3
messages are read-only");
- setting the body to null in a processor gives back the mail;
- CamelMailAlternativeBody is not in the catalog, so the validator rejects
a route that sets it.
- smpp:
- a stream body is sent as an empty short message, and no body fails with
a NullPointerException (Major);
- 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.
- 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, and the
requester times out.
- 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.
- paho and paho-mqtt5: a body that does not convert to bytes fails with a
NullPointerException with no message.
**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.
**Measured.**
- The validator over the 1204 human-written and 1209 model-written route
files gives the same reports as with #28302.
- Body types now cover 94.8% of the endpoint uses in the human-written
routes (93.9% with #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](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
