gnodet commented on code in PR #23193:
URL: https://github.com/apache/camel/pull/23193#discussion_r3234500763
##########
core/camel-api/src/main/java/org/apache/camel/spi/Synchronization.java:
##########
@@ -22,8 +22,7 @@
/**
* Provides a hook for custom {@link org.apache.camel.Processor} or {@link
org.apache.camel.Component} instances to
* respond to completed or failed processing of an {@link Exchange} rather
like Spring's
- * <a
href="http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/transaction/
- * support/TransactionSynchronization.html">TransactionSynchronization</a>
+ * {@code TransactionSynchronization}
Review Comment:
_Claude Code on behalf of Guillaume Nodet_
Good point — updated to use the FQCN: `{@code
org.springframework.transaction.support.TransactionSynchronization}` so it's
clear this refers to a Spring class.
##########
core/camel-api/src/main/java/org/apache/camel/InvalidPayloadRuntimeException.java:
##########
@@ -27,21 +27,41 @@ public class InvalidPayloadRuntimeException extends
RuntimeExchangeException {
private final transient @Nullable Class<?> type;
+ /**
+ * @param exchange the exchange that caused the error
+ * @param type the expected body type
+ */
public InvalidPayloadRuntimeException(Exchange exchange, Class<?> type) {
this(exchange, type, exchange.getIn());
}
+ /**
+ * @param exchange the exchange that caused the error
+ * @param type the expected body type
+ * @param cause the cause of the failure
+ */
public InvalidPayloadRuntimeException(Exchange exchange, Class<?> type,
Throwable cause) {
this(exchange, type, exchange.getIn(), cause);
}
+ /**
+ * @param exchange the exchange that caused the error
+ * @param type the expected body type
+ * @param message the message whose body could not be converted
Review Comment:
_Claude Code on behalf of Guillaume Nodet_
You're right — the description was too narrow. Updated to: `@param message
the message with the invalid or missing payload`. Same fix applied to
`InvalidPayloadException`.
##########
core/camel-api/src/main/java/org/apache/camel/package-info.java:
##########
@@ -18,7 +18,7 @@
* The core Camel API.
*/
@NullMarked
-@XmlSchema(namespace = "http://camel.apache.org/schema/spring";,
+@XmlSchema(namespace = "https://camel.apache.org/schema/spring";,
Review Comment:
_Claude Code on behalf of Guillaume Nodet_
Good catch — the `@XmlSchema` namespace is an XML identifier, not a web URL.
Changing `http://` to `https://` would break namespace matching. Reverted.
##########
core/camel-api/src/main/java/org/apache/camel/Exchange.java:
##########
@@ -39,28 +39,14 @@
* An Exchange is created when a {@link Consumer} receives a request. A new
{@link Message} is created, the request is
* set as the body of the {@link Message} and depending on the {@link
Consumer} other {@link Endpoint} and protocol
* related information is added as headers on the {@link Message}. Then an
Exchange is created and the newly created
- * {@link Message} is set as the in on the Exchange. Therefore, an Exchange
starts its life in a {@link Consumer}. The
- * Exchange is then sent down the {@link Route} for processing along a {@link
Processor} chain. The {@link Processor} as
- * the name suggests is what processes the {@link Message} in the Exchange and
Camel, in addition to providing
- * out-of-the-box a large number of useful processors, it also allows you to
create your own. The rule Camel uses is to
- * take the out {@link Message} produced by the previous {@link Processor} and
set it as the in for the next
- * {@link Processor}. If the previous {@link Processor} did not produce an
out, then the in of the previous
- * {@link Processor} is sent as the next in. At the end of the processing
chain, depending on the {@link ExchangePattern
- * Message Exchange Pattern} (or MEP) the last out (or in of no out available)
is sent by the {@link Consumer} back to
- * the original caller.
+ * {@link Message} is set on the Exchange. Therefore, an Exchange starts its
life in a {@link Consumer}. The Exchange is
+ * then sent down the {@link Route} for processing along a {@link Processor}
chain. The {@link Processor} as the name
+ * suggests is what processes the {@link Message} in the Exchange. Camel
provides a large number of useful processors
+ * out-of-the-box, and it also allows you to create your own.
* <p/>
- * Camel, in addition to providing out-of-the-box a large number of useful
processors, it also allows you to implement
- * and use your own. When the Exchange is passed to a {@link Processor}, it
always contains an in {@link Message} and no
- * out {@link Message}. The {@link Processor} <b>may</b> produce an out,
depending on the nature of the
- * {@link Processor}. The in {@link Message} can be accessed using the {@link
#getIn()} method. Since the out message is
- * null when entering the {@link Processor}, the {@link #getOut()} method is
actually a convenient factory method that
- * will lazily instantiate a {@link org.apache.camel.support.DefaultMessage}
which you could populate. As an alternative
- * you could also instantiate your specialized {@link Message} and set it on
the exchange using the
- * {@link #setOut(org.apache.camel.Message)} method. Please note that a {@link
Message} contains not only the body but
- * also headers and attachments. If you are creating a new {@link Message} the
headers and attachments of the in
- * {@link Message} are not automatically copied to the out by Camel, and
you'll have to set the headers and attachments
- * you need yourself. If your {@link Processor} is not producing a different
{@link Message} but only needs to slightly
- * modify the in, you can simply update the in {@link Message} returned by
{@link #getIn()}.
+ * To access or modify the current message, use the {@link #getMessage()}
method. Camel uses {@link #getMessage()} to
+ * obtain the current message during routing. If a {@link Processor} modifies
the message, those changes are visible to
+ * subsequent processors.
Review Comment:
_Claude Code on behalf of Guillaume Nodet_
The removed paragraphs described the in/out message model
(`getIn()`/`getOut()`/`setOut()`) which was deprecated in Camel 3.0. The old
Javadoc was teaching users a deprecated pattern. The replacement directs users
to `getMessage()` which is the current API. I've also added back a mention of
`ExchangePattern` since MEP is still an active concept.
--
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]
