Skip to content

CAMEL-22549: Replace deprecated Exchange getOut/hasOut/setOut with getMessage API#22358

Draft
gnodet wants to merge 4 commits intoapache:mainfrom
gnodet:CAMEL-22549-clear-deprecation-warnings
Draft

CAMEL-22549: Replace deprecated Exchange getOut/hasOut/setOut with getMessage API#22358
gnodet wants to merge 4 commits intoapache:mainfrom
gnodet:CAMEL-22549-clear-deprecation-warnings

Conversation

@gnodet
Copy link
Copy Markdown
Contributor

@gnodet gnodet commented Mar 31, 2026

CAMEL-22549

Summary

Replaces all deprecated Exchange.getOut(), hasOut(), and setOut() calls with the modern Exchange.getMessage() API across the entire codebase. Introduces four new ExchangeHelper bridge methods to centralize the migration:

  • ExchangeHelper.hasResponse(exchange) — non-deprecated equivalent of hasOut()
  • ExchangeHelper.getResponse(exchange) — returns the response message without lazy creation (unlike getOut())
  • ExchangeHelper.setResponse(exchange, message) — wraps setOut() as the single remaining call site
  • ExchangeHelper.createResponse(exchange) — creates a new empty response and returns it (replaces getOut() lazy-creation pattern)

Why new utility methods?

The new methods are not just renames of the deprecated API — they address the specific problems that led to the deprecation:

  • getResponse()getOut(): getOut() lazily creates a new empty OUT message as a side effect if none exists — a "getter" that silently mutates state. getResponse() returns null if there's no response, with no side effects.
  • createResponse(): For code that relied on getOut() lazy creation, createResponse() makes the intent explicit — it creates a new empty DefaultMessage, sets it as the response, and returns it.
  • hasResponse() avoids deprecated API: Functionally equivalent to hasOut(), but implemented as getIn() != getMessage() — same semantics without calling the deprecated method.
  • setResponse() centralizes the deprecated call: Instead of 50+ scattered setOut() calls, there is now exactly one — inside setResponse(). When the deprecated API is eventually removed, only this single method needs to change.

Migration patterns

Pattern Old code New code Behavioral change?
A getOut().setBody(x) getMessage().setBody(x) No
B getOut().copyFrom(in) setResponse(in.copy()) No
C hasOut() ? getOut() : getIn() getMessage() No
D getOut().setBody(x) (lazy creation) createResponse(exchange).setBody(x) No
E hasOut() → read getOut() getResponse() (returns null if no OUT) Yes — no lazy creation side effect
F setOut(null) setResponse(null) No

Pattern D uses createResponse() which creates a new DefaultMessage() — used where code relied on getOut() creating an empty OUT message (e.g., HttpProducer, JcrProducer, UnmarshalProcessor). Where IN headers should propagate to the response (e.g., bean, enricher), setResponse(exchange.getIn().copy()) is used instead.

Pattern E is the only behavioral change: getResponse() returns null instead of lazily creating an empty message. Code using this pattern now has explicit null checks.

Follow-up

A follow-up PR will propose adding hasResponse(), getResponse(), setResponse(), and createResponse() directly to the Exchange interface, replacing the deprecated hasOut()/getOut()/setOut() methods.

Changes

Core infrastructure

  • ExchangeHelper: Added 4 new utility methods + migrated 13 internal methods
  • CamelConverter: Migrated toProcessor() for Expression and Predicate
  • MarshalProcessor / UnmarshalProcessor: Migrated to createResponse() / setResponse() + getMessage()
  • DefaultExchangeHolder: Migrated marshal/unmarshal; unmarshal now reuses existing response to preserve message type (e.g., JmsMessage)

Core processors

  • Enricher / PollEnricher: getOut().copyFrom(getIn())setResponse(getIn().copy())
  • TransformProcessor: hasOut()hasResponse()
  • WireTapProcessor / OnCompletionProcessor: Migrated to prepareOutToIn()
  • RedeliveryErrorHandler: 3 locations migrated

Components (production code)

  • camel-bean: MethodInfo (structural change — in.copy() replaces getOut() + manual header propagation), BeanExpression (getResponse() returns null for void methods)
  • camel-jms / camel-sjms: instanceof pattern replaces hasOut() + getOut(Class)
  • camel-netty: ClientChannelHandler (skips response pre-creation for DefaultExchangeHolder)
  • camel-http: HttpProducer (createResponse() for header isolation)
  • camel-xslt: XsltBuilder (conditional "out" transformer param avoids side-effect OUT creation)
  • camel-xpath: XPathBuilder (deprecated out:body/out:header functions now null-safe)
  • camel-cxf: CxfRsInvoker, CamelDestination (createResponse())
  • camel-file: GenericFile
  • camel-jcr: JcrProducer (createResponse())
  • camel-mina: MinaPayloadHelper (renamed methods), MinaConsumer, MinaProducer
  • And 10+ more components with mechanical Pattern A/B/C migrations

Tests

  • 8 new unit tests for ExchangeHelper.hasResponse/getResponse/setResponse/createResponse
  • 18 test files updated to remove incidental deprecated API usage

Documentation

  • Upgrade guide entry in camel-4x-upgrade-guide-4_19.adoc

Test plan

  • All affected modules compile successfully
  • Code formatted with mvn formatter:format impsort:sort
  • Unit tests for new ExchangeHelper methods pass
  • CI green on JDK 17, 21, and 25
  • Re-verify CI after latest changes

@gnodet gnodet requested review from davsclaus and oscerd March 31, 2026 12:10
@github-actions
Copy link
Copy Markdown
Contributor

🌟 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 build-all, build-dependents, 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.

Copy link
Copy Markdown
Contributor Author

@gnodet gnodet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code on behalf of Guillaume Nodet

Self-review: inline comments explaining why each change pattern is valid.

@gnodet gnodet marked this pull request as draft April 1, 2026 09:02
@gnodet gnodet marked this pull request as ready for review April 7, 2026 13:34
@gnodet gnodet marked this pull request as draft April 7, 2026 13:42
@gnodet gnodet changed the title CAMEL-22549: Replace deprecated Exchange getOut/hasOut/setOut with getMessage CAMEL-22549: Replace deprecated Exchange getOut/hasOut/setOut with getMessage API Apr 7, 2026
@gnodet gnodet marked this pull request as ready for review April 7, 2026 16:17
@gnodet gnodet marked this pull request as draft April 7, 2026 18:12
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented Apr 7, 2026

Quality Gate Failed Quality Gate failed

Failed conditions
27.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Copy link
Copy Markdown
Contributor Author

@gnodet gnodet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code on behalf of Guillaume Nodet

Self-review of the getOut()getMessage() migration. The PR introduces three new ExchangeHelper utility methods (hasResponse, getResponse, setResponse) that wrap the deprecated Exchange.hasOut(), getOut(), setOut() calls into a single deprecated call site. The changes fall into several patterns explained inline below.

Migration patterns used:

Pattern Old code New code Behavioral change?
A getOut().setBody(x) getMessage().setBody(x) No — getMessage() returns OUT if it exists, IN otherwise
B getOut().copyFrom(in) setResponse(in.copy()) No — equivalent, creates OUT with IN content
C hasOut() ? getOut() : getIn() getMessage() No — exact same semantics
D getOut().setBody(x) (lazy creation) setResponse(new DefaultMessage()) + getMessage().setBody(x) No — explicit creation replaces lazy creation
E hasOut() → read getOut() getResponse() (returns null if no OUT) Yes — no lazy creation side effect
F setOut(null) setResponse(null) No — mechanical rename

result = resultExchange.hasOut() ? resultExchange.getOut().getBody() : null;
// the bean component creates an OUT for non-void methods on OUT-capable exchanges,
// so getResponse() returns null for void methods (no result) and the OUT for non-void
Message response = ExchangeHelper.getResponse(resultExchange);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern E: getResponse() returns null for void methods

The bean component only creates an OUT for non-void methods on OUT-capable exchanges. getResponse() returns null when no OUT exists (void method case), unlike getOut() which would have lazily created an empty one. The null check below handles this correctly.


Message answer = exchange.getOut();
// separate response from request so response headers don't mix with request headers
ExchangeHelper.setResponse(exchange, new DefaultMessage(exchange.getContext()));
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern D: explicit new DefaultMessage() to isolate response from request

Uses an empty message (not in.copy()) so that HTTP response headers don't mix with request headers. This preserves the old getOut() behavior which also created an empty message.

if (payload.outBody != null) {
exchange.getOut().setBody(payload.outBody);
// reuse existing response message to preserve its type (e.g. JmsMessage)
if (!ExchangeHelper.hasResponse(exchange)) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reuse existing response message to preserve its type

When unmarshalling a transferExchange payload, the OUT message may already be a specialized type (e.g., JmsMessage). The old code unconditionally replaced it with a DefaultMessage, losing the type. Now we only create a new one if none exists.

NettyPayloadHelper.setOut(exchange, body);
return exchange.getOut();
// DefaultExchangeHolder unmarshals its own OUT, so only pre-create one for normal payloads
if (!(body instanceof DefaultExchangeHolder)) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern D with guard: skip pre-creation for DefaultExchangeHolder

When transferExchange=true, the body is a DefaultExchangeHolder whose unmarshal() sets up its own OUT message. Pre-creating one here would be overwritten. For normal payloads, we create OUT from in.copy() so setPayload() populates the response via getMessage().

transformer.setParameter("in", exchange.getIn());
transformer.setParameter("out", exchange.getOut());
// only set "out" param if a response exists; avoids creating an empty OUT as side effect
Message response = ExchangeHelper.getResponse(exchange);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern E: conditional parameter avoids side-effect OUT creation

The old code always called exchange.getOut() which lazily created an empty OUT as a side effect. Now we only set the "out" transformer parameter if a response actually exists.

// so that it can mutate it if necessary
Message out = exchange.getOut();
out.copyFrom(in);
ExchangeHelper.setResponse(exchange, in.copy());
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern B: setResponse(in.copy()) replaces getOut().copyFrom(in)

Mechanically equivalent. The same pattern is used in UnmarshalProcessor, Enricher.prepareResult(), PollEnricher.prepareResult(), CamelConverter, and ExchangeHelper.setInOutBodyPatternAware().

protected void setMessageId(Exchange exchange) {
if (exchange.hasOut()) {
JmsMessage out = exchange.getOut(JmsMessage.class);
if (ExchangeHelper.getResponse(exchange) instanceof JmsMessage out) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern E: instanceof replaces hasOut() + getOut(Class)

getResponse() returns null when no OUT exists, and instanceof naturally handles null (evaluates to false). This is more concise than the old hasOut() guard + cast. Same pattern in SjmsProducer.setMessageId().

}
node.addMixin("mix:referenceable");
exchange.getOut().setBody(node.getIdentifier());
ExchangeHelper.setResponse(exchange, new DefaultMessage(exchange.getContext()));
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern D: explicit response creation replaces getOut().setBody()

The old getOut().setBody(id) lazily created an empty OUT and set the body. Now we explicitly create the response. Uses new DefaultMessage() (not in.copy()) because the response body (node UUID) is unrelated to the request body. Same pattern in CxfRsInvoker.

if (exchange.get() != null && exchange.get().hasOut()) {
return exchange.get().getOut().getBody();
if (exchange.get() != null) {
Message response = ExchangeHelper.getResponse(exchange.get());
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern E + deprecated: out:body() / out:header() now null-safe

The old getOut().getBody() would lazily create an empty OUT (side effect). Now getResponse() returns null when no OUT exists, and we return null instead. The getter/setter methods for these functions are also marked @Deprecated.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 8, 2026

🧪 CI tested the following changed modules:

  • components/camel-ai/camel-chatscript
  • components/camel-avro-rpc/camel-avro-rpc-component
  • components/camel-barcode
  • components/camel-bean
  • components/camel-beanio
  • components/camel-bindy
  • components/camel-coap
  • components/camel-cometd
  • components/camel-crypto-pgp
  • components/camel-crypto
  • components/camel-cxf/camel-cxf-rest
  • components/camel-cxf/camel-cxf-spring-soap
  • components/camel-cxf/camel-cxf-transport
  • components/camel-exec
  • components/camel-file
  • components/camel-fop
  • components/camel-github
  • components/camel-hl7
  • components/camel-http
  • components/camel-influxdb
  • components/camel-influxdb2
  • components/camel-ironmq
  • components/camel-jackson
  • components/camel-jackson3
  • components/camel-jackson3xml
  • components/camel-jacksonxml
  • components/camel-jcr
  • components/camel-jms
  • components/camel-jooq
  • components/camel-mina
  • components/camel-mock
  • components/camel-mvel
  • components/camel-mybatis
  • components/camel-netty-http
  • components/camel-netty
  • components/camel-ognl
  • components/camel-olingo2/camel-olingo2-component
  • components/camel-olingo4/camel-olingo4-component
  • components/camel-quickfix
  • components/camel-reactive-streams
  • components/camel-rest
  • components/camel-rocketmq
  • components/camel-salesforce/camel-salesforce-component
  • components/camel-sap-netweaver
  • components/camel-saxon
  • components/camel-sjms
  • components/camel-smooks
  • components/camel-soap
  • components/camel-spring-parent/camel-spring-batch
  • components/camel-spring-parent/camel-spring-ws
  • components/camel-spring-parent/camel-spring
  • components/camel-sql
  • components/camel-ssh
  • components/camel-stax
  • components/camel-undertow
  • components/camel-vertx/camel-vertx
  • components/camel-xmlsecurity
  • components/camel-xpath
  • components/camel-xslt
  • core/camel-base
  • core/camel-core-processor
  • core/camel-core
  • core/camel-support
  • docs

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

  • components/camel-http: 1 test(s) disabled on GitHub Actions
  • components/camel-jms: 8 test(s) disabled on GitHub Actions
  • components/camel-netty: 1 test(s) disabled on GitHub Actions
  • components/camel-rocketmq: 2 test(s) disabled on GitHub Actions
  • components/camel-sjms: 1 test(s) disabled on GitHub Actions
  • components/camel-undertow: 1 test(s) disabled on GitHub Actions
  • core/camel-core: 18 test(s) disabled on GitHub Actions
Build reactor — dependencies compiled but only changed modules were tested (64 modules)
  • Camel :: AI :: ChatScript
  • Camel :: Avro RPC
  • Camel :: Barcode
  • Camel :: Base
  • Camel :: Bean
  • Camel :: BeanIO
  • Camel :: Bindy
  • Camel :: CXF :: REST
  • Camel :: CXF :: SOAP :: Spring
  • Camel :: CXF :: Transport
  • Camel :: CoAP
  • Camel :: Cometd
  • Camel :: Core
  • Camel :: Core Processor
  • Camel :: Crypto
  • Camel :: Crypto PGP
  • Camel :: Docs
  • Camel :: Exec
  • Camel :: FOP
  • Camel :: File
  • Camel :: GitHub
  • Camel :: HL7
  • Camel :: HTTP
  • Camel :: InfluxDB
  • Camel :: InfluxDB2
  • Camel :: IronMQ
  • Camel :: JCR
  • Camel :: JMS
  • Camel :: JOOQ
  • Camel :: Jackson
  • Camel :: Jackson 3
  • Camel :: Jackson 3 XML
  • Camel :: Jackson XML
  • Camel :: MINA
  • Camel :: MVEL
  • Camel :: Mock
  • Camel :: MyBatis
  • Camel :: Netty
  • Camel :: Netty HTTP
  • Camel :: OGNL (deprecated)
  • Camel :: Olingo2 (Deprecated) :: Component
  • Camel :: Olingo4 (Deprecated) :: Component
  • Camel :: QuickFIX/J
  • Camel :: REST
  • Camel :: Reactive Streams
  • Camel :: RocketMQ
  • Camel :: SAP NetWeaver
  • Camel :: SOAP
  • Camel :: SQL
  • Camel :: SSH
  • Camel :: Salesforce
  • Camel :: Saxon
  • Camel :: Simple JMS
  • Camel :: Smooks :: Parent
  • Camel :: Spring
  • Camel :: Spring Batch
  • Camel :: Spring Web Services
  • Camel :: StAX
  • Camel :: Support
  • Camel :: Undertow
  • Camel :: Vertx
  • Camel :: XML Security
  • Camel :: XPath
  • Camel :: XSLT

⚙️ View full build and test results

gnodet and others added 3 commits April 8, 2026 10:51
…odules

Introduce hasResponse(), getResponse(), setResponse() in ExchangeHelper
as non-deprecated replacements for Exchange.hasOut()/getOut()/setOut().
Migrate all core modules: ExchangeHelper internals, CamelConverter,
MarshalProcessor, UnmarshalProcessor, DefaultExchangeHolder, Enricher,
PollEnricher, TransformProcessor, WireTapProcessor, OnCompletionProcessor,
and RedeliveryErrorHandler.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…essage API

Replace deprecated Exchange.getOut(), hasOut(), setOut() with
ExchangeHelper.hasResponse(), getResponse(), setResponse() and
Exchange.getMessage() across all affected components including:
bean, cxf, http, jms, sjms, netty, mina, xpath, xslt, file, jcr,
salesforce, xmlsecurity, and 30+ others.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…uide

Add 7 unit tests for ExchangeHelper.hasResponse/getResponse/setResponse.
Update 18 test files to remove incidental deprecated API usage.
Add upgrade guide entry in camel-4x-upgrade-guide-4_19.adoc documenting
the new ExchangeHelper utilities for component developers.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@gnodet gnodet force-pushed the CAMEL-22549-clear-deprecation-warnings branch from d697782 to b6889f7 Compare April 8, 2026 08:51
@github-actions github-actions bot added the docs label Apr 8, 2026
Comment on lines +1316 to +1356
public static boolean hasResponse(Exchange exchange) {
return exchange.getIn() != exchange.getMessage();
}

/**
* Returns the response message if one has been explicitly set, null otherwise. Unlike the deprecated
* {@link Exchange#getOut()}, this does NOT lazily create an empty message.
* <p>
* This is provided as a utility until a proper {@code getResponse()} method is added to the {@link Exchange} API.
*/
public static Message getResponse(Exchange exchange) {
return hasResponse(exchange) ? exchange.getMessage() : null;
}

/**
* Sets the response message on this exchange. Unlike {@link Exchange#getOut()} which lazily creates an empty
* message on read, this makes response creation explicit.
* <p>
* This is a non-deprecated equivalent of {@link Exchange#setOut(Message)}, provided as a utility until a proper
* {@code setResponse(Message)} method is added to the {@link Exchange} API.
*/
@SuppressWarnings("deprecation")
public static void setResponse(Exchange exchange, Message response) {
exchange.setOut(response);
}

/**
* Creates a new empty response message on the exchange and returns it. This is the non-deprecated equivalent of the
* lazy-creation side effect of {@link Exchange#getOut()}.
* <p>
* Typical usage:
*
* <pre>
* Message response = ExchangeHelper.createResponse(exchange);
* response.setBody(result);
* </pre>
*/
public static Message createResponse(Exchange exchange) {
setResponse(exchange, new DefaultMessage(exchange.getContext()));
return exchange.getMessage();
}
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Foundation: four new utility methods

These four methods (hasResponse, getResponse, setResponse, createResponse) are the non-deprecated equivalents of hasOut(), getOut(), setOut(). They live in ExchangeHelper as a stepping stone — the plan is to eventually promote them to the Exchange API itself.

Key semantic difference from getOut(): getResponse() returns null when no response exists (no lazy creation side-effect). For code that needs the old lazy-creation behavior, use createResponse().

Claude Code on behalf of Guillaume Nodet

Comment on lines 395 to +403
private void fillResult(Exchange exchange, Object result) {
LOG.trace("Setting bean invocation result : {}", result);

// the bean component forces OUT if the MEP is OUT capable
boolean out = exchange.hasOut() || ExchangeHelper.isOutCapable(exchange);
Message old;
if (out) {
old = exchange.getOut();
// propagate headers
exchange.getOut().getHeaders().putAll(exchange.getIn().getHeaders());
} else {
old = exchange.getIn();
// the bean component forces OUT if the MEP is OUT capable;
// in.copy() both creates the OUT and propagates headers in one step
if (ExchangeHelper.isOutCapable(exchange) && !ExchangeHelper.hasResponse(exchange)) {
ExchangeHelper.setResponse(exchange, exchange.getIn().copy());
}
Message old = exchange.getMessage();
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern B: in.copy() replaces getOut() + manual header propagation

The old code did:

boolean out = exchange.hasOut() || ExchangeHelper.isOutCapable(exchange);
if (out) {
    old = exchange.getOut();           // lazily creates empty OUT
    exchange.getOut().getHeaders().putAll(exchange.getIn().getHeaders());  // manual propagation
} else {
    old = exchange.getIn();
}

Now in.copy() both creates the OUT and propagates headers in one step. The guard !hasResponse(exchange) avoids overwriting if an OUT already exists from an earlier processor in the chain.

Claude Code on behalf of Guillaume Nodet

Comment on lines 443 to +449
public static Message getResultMessage(Exchange exchange) {
if (exchange.getPattern().isOutCapable()) {
return exchange.getOut();
// explicitly create response if none exists (preserves old getOut() lazy-creation semantics)
if (!hasResponse(exchange)) {
return createResponse(exchange);
}
return exchange.getMessage();
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explicit response creation preserves getOut() lazy-creation semantics

getResultMessage() is used by CXF, SOAP, and other components that expect an OUT message to exist after calling this method. The old code returned exchange.getOut() which lazily created an empty OUT as a side effect. The new code makes this explicit via createResponse() — the intent is now visible in the code rather than hidden behind a getter.

Claude Code on behalf of Guillaume Nodet

@gnodet gnodet force-pushed the CAMEL-22549-clear-deprecation-warnings branch from 5fc83d2 to 468ad7f Compare April 8, 2026 09:48
Introduce createResponse(exchange) that creates a new empty response
message and returns it, simplifying the common two-step pattern of
setResponse() + getMessage(). Refactored 7 call sites across core
and components to use the new utility.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@gnodet gnodet force-pushed the CAMEL-22549-clear-deprecation-warnings branch from 468ad7f to ea607bc Compare April 8, 2026 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant