Add Cloud Events support to Spring Integration #10448

cppwfs · 2025-09-26T20:28:11Z

Introduces Cloud Events v1.0 specification support including message converters, transformers, and utilities.

Key components added:

CloudEventMessageConverter for message format conversion
ToCloudEventTransformer for transforming messages to Cloud Events
MessageBinaryMessageReader/Writer for binary format handling
CloudEventProperties for configuration management
Header pattern matching utilities for flexible event mapping
Add reference docs and what's-new paragraph

artembilan

Left some at a glance review.

Thank you!

build.gradle

...src/main/java/org/springframework/integration/cloudevents/v1/CloudEventMessageConverter.java

...g/springframework/integration/cloudevents/v1/transformer/CloudEventMessageConverterTest.java

src/reference/antora/modules/ROOT/pages/whats-new.adoc

artembilan

Sorry for a lengthy review and some doubts I've expressed.

I addition, what are your thoughts about content of this package in Spring Cloud Function: https://github.com/spring-cloud/spring-cloud-function/tree/main/spring-cloud-function-context/src/main/java/org/springframework/cloud/function/cloudevent ?

I mean transformer does the trick indeed, but only from an integration flow context.
How about the way to be able to construct CloudEvent programmatically?
Or just existing SDK API is enough to deal with?

artembilan · 2025-09-29T13:55:13Z

...ts/src/main/java/org/springframework/integration/cloudevents/CloudEventMessageConverter.java

+		return CloudEventUtils.toReader((CloudEvent) payload).read(new MessageBuilderMessageWriter(headers, this.cePrefix));
+	}
+
+	private MessageReader createMessageReader(Message<?> message) {


Looks like all of methods starting with this has to be static.

Has not been addressed yet.

...ation/cloudevents/transformer/strategies/cloudeventconverter/CloudEventMessageConverter.java

...ation/cloudevents/transformer/strategies/cloudeventconverter/MessageBinaryMessageReader.java

...pringframework/integration/cloudevents/v1/transformer/ToCloudEventTransformerExtensions.java

...a/org/springframework/integration/cloudevents/v1/transformer/utils/HeaderPatternMatcher.java

...java/org/springframework/integration/cloudevents/v1/transformer/ToCloudEventTransformer.java

artembilan · 2025-09-29T14:17:43Z

.../main/java/org/springframework/integration/cloudevents/transformer/CloudEventProperties.java

+ *
+ * @since 7.0
+ */
+public class CloudEventProperties {


I'm not sure in this class.
Why all these properties cannot be on the transformer itself?
More over: how about expressions against the request message to determine all these options at runtime?
I think I had expressions in my original PoC: #3246.

Any comments here, please?

artembilan · 2025-09-29T14:20:48Z

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

+ *
+ * @since 7.0
+ */
+public final class CloudEventsHeaders {


I'm not very convinced that we need this class at all.
Especially with the case when we can change the prefix.

Any comments, please?

CloudEventHeaders can be changed from a class to a record, since it only contains constants. The CE_PREFIX is used across all packages in the module.

Sorry, but I have to disagree.
Whatever place you use it is just artificial, having the fact that prefix could be customized.
I prefer to not have these constants at all.
We can just have ce- hardcoded in the transformer (or converter).
As long as those specversion and datacontenttype.
Just because they simply become totally different values when we change the prefix (or don't use it at all).

src/reference/antora/modules/ROOT/pages/cloudevents/cloudevents-transform.adoc

artembilan · 2025-10-06T17:33:28Z

...ts/src/main/java/org/springframework/integration/cloudevents/CloudEventMessageConverter.java

+		return CloudEventUtils.toReader((CloudEvent) payload).read(new MessageBuilderMessageWriter(headers, this.cePrefix));
+	}
+
+	private MessageReader createMessageReader(Message<?> message) {


Has not been addressed yet.

artembilan · 2025-10-06T17:33:46Z

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

+ *
+ * @since 7.0
+ */
+public final class CloudEventsHeaders {


Any comments, please?

artembilan · 2025-10-06T17:35:41Z

...ts/src/main/java/org/springframework/integration/cloudevents/MessageBinaryMessageReader.java

+
+import io.cloudevents.SpecVersion;
+import io.cloudevents.core.data.BytesCloudEventData;
+import io.cloudevents.core.impl.StringUtils;


Please, consider to use org.springframework.util.StringUtils instead.
I guess, the one in CloudEvents is just a copy of ours 😄

artembilan · 2025-10-06T17:35:58Z

...ts/src/main/java/org/springframework/integration/cloudevents/MessageBinaryMessageReader.java

+
+	@Override
+	protected boolean isContentTypeHeader(String key) {
+		return org.springframework.messaging.MessageHeaders.CONTENT_TYPE.equalsIgnoreCase(key);


Why do we need FQCN?

artembilan · 2025-10-06T17:38:35Z

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java

+
+	@Override
+	public Message<byte[]> end() {
+		return MessageBuilder.withPayload(new byte[0]).copyHeaders(this.headers).build();


Looks like we could just call end(null) from here to avoid duplication.

Not exactly. In this implementation the copyHeaders is called while in the end(null) does not.

Sorry, but I have to disagree.
Please, take a look into those two lines again:

MessageBuilder.withPayload(new byte[0]).copyHeaders(this.headers).build(); ... MessageBuilder.withPayload(value == null ? new byte[0] : value.toBytes()).copyHeaders(this.headers).build();

You are correct I missed the parenthesis before the copyHeaders on my read . Will adjust.
Thank you for catching this.

artembilan · 2025-10-06T17:47:51Z

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java

+ *
+ * @since 7.0
+ */
+public class MessageBuilderMessageWriter


DITTO.
Why public?

artembilan · 2025-10-06T17:49:32Z

...g/springframework/integration/cloudevents/transformer/ToCloudEventTransformerExtensions.java

+	private final Map<String, Object> filteredHeaders;
+
+	/**
+	 * Constructs CloudEvent extensions by filtering message headers against patterns.


The method Javadoc must be imperative, like a command, not infinitive.

artembilan · 2025-10-06T17:51:44Z

...g/springframework/integration/cloudevents/transformer/ToCloudEventTransformerExtensions.java

+	}
+
+	public Map<String, Object> getFilteredHeaders() {
+		return this.filteredHeaders;


I don't think that filtering has to be a part of this implementation.
I think the transformer has to do the trick for categorizing headers.
And from there, it looks like this whole class could go as inner one into the transformer.

artembilan · 2025-10-06T18:04:53Z

.../java/org/springframework/integration/cloudevents/transformer/strategies/FormatStrategy.java

+	 * @param messageHeaders the headers associated with the {@link Message}
+	 * @return the converted {@link Message}
+	 */
+	Message<?> convert(CloudEvent cloudEvent, MessageHeaders messageHeaders);


I'm not sure in this contract.
Looks like a duplication of the MessageConverter.
I expected here something similar what you had before in the transformer for XML, AVRO etc.

Right. So, I found an original code in your first commit (sorry again for the noise!):

AvroCompactFormat avroFormat = new AvroCompactFormat(); byte[] avroBytes = avroFormat.serialize(cloudEvent); return MessageBuilder.withPayload(avroBytes) .copyHeaders(filterHeaders(originalHeaders)) .setHeader("content-type", "application/avro") .build();

Therefore I imaging the strategy like this:

public interface FormatStrategy { byte[] toByteArray(CloudEvent cloudEvent); String getContentType(); }

And from here it sounds like a part of that our CloudEventMessageConverter.

WDYT?

Let's discuss. I'm not sure I understand.

artembilan · 2025-10-06T18:05:57Z

...t/java/org/springframework/integration/cloudevents/transformer/CloudEventPropertiesTest.java

+
+import static org.assertj.core.api.Assertions.assertThat;
+
+class CloudEventPropertiesTest {


As I said before: I'm not sure in the CloudEventProperties class at all.
And our preferences is *Tests for test class names.
Please, revise all of your new test classes.

build.gradle

cppwfs · 2025-10-06T19:11:48Z

For now hold off on a review. I'm writing up some questions for some guidance on some of the issues you raised in the last 2 reviews.

artembilan · 2025-10-06T20:55:26Z

.../java/org/springframework/integration/cloudevents/transformer/strategies/FormatStrategy.java

+	 * @param messageHeaders the headers associated with the {@link Message}
+	 * @return the converted {@link Message}
+	 */
+	Message<?> convert(CloudEvent cloudEvent, MessageHeaders messageHeaders);


Right. So, I found an original code in your first commit (sorry again for the noise!):

AvroCompactFormat avroFormat = new AvroCompactFormat(); byte[] avroBytes = avroFormat.serialize(cloudEvent); return MessageBuilder.withPayload(avroBytes) .copyHeaders(filterHeaders(originalHeaders)) .setHeader("content-type", "application/avro") .build();

Therefore I imaging the strategy like this:

public interface FormatStrategy { byte[] toByteArray(CloudEvent cloudEvent); String getContentType(); }

And from here it sounds like a part of that our CloudEventMessageConverter.

WDYT?

Introduces Cloud Events v1.0 specification support including message converters, transformers, and utilities. Key components added: - CloudEventMessageConverter for message format conversion - ToCloudEventTransformer for transforming messages to Cloud Events - MessageBinaryMessageReader/Writer for binary format handling - CloudEventProperties for configuration management - Header pattern matching utilities for flexible event mapping - Add reference docs and what's-new paragraph

Remove v1 subpackage and flatten the CloudEvents package hierarchy. Introduce strategy pattern for format conversion to replace enum-based approach, improving extensibility and reduce dependencies. Key changes: - Move all classes from cloudevents.v1 to cloudevents base package - Remove optional format dependencies (JSON, XML, Avro) from build - Replace `ConversionType` enum with `FormatStrategy` interface - Add `CloudEventMessageFormatStrategy` as default implementation - Inline `HeaderPatternMatcher` logic into `ToCloudEventTransformerExtensions` - Add `@NullMarked` package annotations and `@Nullable` throughout - Document `targetClass` parameter behavior in `CloudEventMessageConverter` - Split transformer tests for better organization and coverage - Update component type identifier to "ce:to-cloudevents-transformer" - Remove unnecessary docs from package-info

artembilan · 2025-10-07T14:43:12Z

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java

+
+	@Override
+	public Message<byte[]> end() {
+		return MessageBuilder.withPayload(new byte[0]).copyHeaders(this.headers).build();


Sorry, but I have to disagree.
Please, take a look into those two lines again:

MessageBuilder.withPayload(new byte[0]).copyHeaders(this.headers).build(); ... MessageBuilder.withPayload(value == null ? new byte[0] : value.toBytes()).copyHeaders(this.headers).build();

artembilan · 2025-10-07T14:46:44Z

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

+ *
+ * @since 7.0
+ */
+public final class CloudEventsHeaders {


Sorry, but I have to disagree.
Whatever place you use it is just artificial, having the fact that prefix could be customized.
I prefer to not have these constants at all.
We can just have ce- hardcoded in the transformer (or converter).
As long as those specversion and datacontenttype.
Just because they simply become totally different values when we change the prefix (or don't use it at all).

- Simplify the CloudEvent transformer by consolidating configuration directly into ToCloudEventTransformer class rather than using separate configuration objects - Remove CloudEventProperties and ToCloudEventTransformerExtensions classes to reduce abstraction layers and improve maintainability - Make MessageBinaryMessageReader package-private and convert CloudEventMessageConverter methods to static where possible - Move extension filtering logic into a private inner class within the transformer - Remove CloudEventsHeaders class and CE_PREFIX constant as the prefix is no longer used as a configurable value

cppwfs requested a review from artembilan September 26, 2025 20:28

cppwfs force-pushed the SI-cloud-events branch 2 times, most recently from 03d1f51 to 02a1329 Compare September 26, 2025 20:47

artembilan requested changes Sep 26, 2025

View reviewed changes

artembilan requested changes Sep 29, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch 2 times, most recently from cabc5e5 to d14c5f8 Compare October 6, 2025 15:32

artembilan requested changes Oct 6, 2025

View reviewed changes

build.gradle Show resolved Hide resolved

artembilan requested changes Oct 6, 2025

View reviewed changes

cppwfs added 2 commits October 7, 2025 08:28

artembilan requested changes Oct 7, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch from d14c5f8 to d8989f9 Compare October 7, 2025 21:38


		import static org.assertj.core.api.Assertions.assertThat;

		class CloudEventPropertiesTest {

Add Cloud Events support to Spring Integration #10448

Are you sure you want to change the base?

Add Cloud Events support to Spring Integration #10448

Uh oh!

Conversation

cppwfs commented Sep 26, 2025

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cppwfs commented Oct 6, 2025

Uh oh!

Choose a reason for hiding this comment