Add Jackson JSON serialization for JdbcChannelMessageStore #10508

yybmion · 2025-10-18T15:14:50Z

Fixes : #9312

JSON serialization as an alternative to Java serialization, enabling text-based message storage with type information preservation.

Add JacksonChannelMessageStorePreparedStatementSetter for serialization
Add JacksonMessageRowMapper for deserialization
Include JSON-compatible schemas for PostgreSQL (JSONB), MySQL (JSON), and H2 (CLOB)
Add comprehensive test coverage with database-specific tests
Add documentation for JSON serialization support

yybmion · 2025-10-18T15:28:53Z

Hi, I'd like your input on two decisions

1. Column naming: `MESSAGE_BYTES` or `MESSAGE_CONTENT`.

I kept MESSAGE_BYTES to avoid creating custom QueryProviders for each database. While semantically it should be MESSAGE_CONTENT (since it's now JSON, not binary), renaming would require:

Custom PostgresJsonChannelMessageStoreQueryProvider
Custom MySqlJsonChannelMessageStoreQueryProvider
Custom H2JsonChannelMessageStoreQueryProvider
Maintaining separate query implementations

The current approach works as a drop-in replacement - users just change the schema file. Is this acceptable, or should I implement the custom QueryProviders for better naming?

2. Database coverage: PostgreSQL, MySQL, H2 only

I've implemented and tested these three databases. Should I:

Add untested schemas for Oracle/SQL Server/Derby/DB2 based on documentation?
Keep only tested databases and add others in follow-up PRs?

I lean toward starting with tested databases only.

What do you think?

artembilan

Please, add your legal name to the sign-off of the commit.
You can change your Git client config on the matter.

artembilan · 2025-10-20T14:57:58Z

build.gradle

    jmsApiVersion = '3.1.0'
    jpaApiVersion = '3.2.0'
    jrubyVersion = '10.0.2.0'
+    jsonassertVersion = '1.5.1'


Any real justification to manage an extra dependency?

artembilan · 2025-10-20T14:58:33Z

...mework/integration/jdbc/store/channel/JacksonChannelMessageStorePreparedStatementSetter.java

+	 * </ul>
+	 * <p>
+	 * <b>Note:</b> Subpackages are automatically included without wildcards.
+	 *


No blank lines in method Javadocs, please.

artembilan · 2025-10-20T15:02:39Z

...mework/integration/jdbc/store/channel/JacksonChannelMessageStorePreparedStatementSetter.java

+	 *
+	 * @param trustedPackages the additional packages to trust for deserialization
+	 */
+	public JacksonChannelMessageStorePreparedStatementSetter(String... trustedPackages) {


The security is not consulted on the serialization, therefore this option is redundant here.

artembilan · 2025-10-20T15:13:39Z

...mework/integration/jdbc/store/channel/JacksonChannelMessageStorePreparedStatementSetter.java

+ * schemas from {@code schema-*-json.sql} files.
+ *
+ * @author Yoobin Yoon
+ * @since 7.0


Blank line after @author list.
Just to emphasize who exactly did the change.

artembilan · 2025-10-20T15:13:46Z

...mework/integration/jdbc/store/channel/JacksonChannelMessageStorePreparedStatementSetter.java

+	 *
+	 * @param trustedPackages the additional packages to trust for deserialization
+	 */
+	public JacksonChannelMessageStorePreparedStatementSetter(String... trustedPackages) {


This is something what is not used on serialization. Therefore this option is redundant.

artembilan · 2025-10-20T15:28:36Z

.../springframework/integration/jdbc/store/channel/PostgresJacksonChannelMessageStoreTests.java

+@ContextConfiguration
+public class PostgresJacksonChannelMessageStoreTests extends AbstractJacksonChannelMessageStoreTests {
+
+	private static final PostgreSQLContainer<?> POSTGRES_CONTAINER =


Why doesn't PostgresContainerTest API work for this test scope?
Therefore, might be the case that this class has to go that postgres package in our tests.

artembilan · 2025-10-20T15:30:42Z

...n-jdbc/src/test/java/org/springframework/integration/jdbc/store/channel/TestMailMessage.java

+ *
+ * @author Yoobin Yoon
+ */
+public class TestMailMessage implements Serializable {


If we talk about JSON, then Serializable is something redundant.
I also wonder why this class is not a Java record.

artembilan · 2025-10-20T15:33:47Z

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

 See xref:jdbc/lock-registry.adoc[] for more information.

+The `JdbcChannelMessageStore` now supports built-in Jackson JSON serialization as an alternative to Java serialization, enabling human-readable message storage.
+New components `JacksonChannelMessageStorePreparedStatementSetter` and `JacksonMessageRowMapper` provide this functionality with JSON-specific database schemas for PostgreSQL, MySQL, and H2.


I don't think it has any specific value to mention those DBs.
I believe that any CLOB-supporting DB is OK to have a JSON as its value.
So, your statement about JSON-specific database schemas does not reflect reality somehow...
Maybe you meant those custom schema files?
Then, OK: since we talk about dropping them in favor of docs, then this sentence would be changed as well.

artembilan · 2025-10-20T15:38:16Z

src/reference/antora/modules/ROOT/pages/jdbc/message-store-json.adoc

+= JDBC Channel Message Store JSON Serialization
+
+Version 7.0 introduced Jackson JSON serialization support for `JdbcChannelMessageStore`.
+By default, Spring Integration uses Java serialization to store messages in the database as binary BLOB data, which is not human-readable.


The "human-readable" statement makes me think twice.
Is it really a goal to let DBA to read the content of messages?
In most cases the payload and headers contain sensitive business data.
So, expose such an info DB directly might not be very secure.
May we at least don't emphasize somehow that it is better than byte[]?
From my point of view it is even dangerous.
I know that we can encode data in DBs, but let's at least don't mention that it is human-readable!

artembilan · 2025-10-20T15:45:21Z

src/reference/antora/modules/ROOT/pages/jdbc/message-store-json.adoc

+
+Version 7.0 introduced Jackson JSON serialization support for `JdbcChannelMessageStore`.
+By default, Spring Integration uses Java serialization to store messages in the database as binary BLOB data, which is not human-readable.
+The new JSON serialization support allows messages to be stored as readable JSON, making debugging and troubleshooting significantly easier.


Yes, and this sentence also drops any data protection rules away.

yybmion · 2025-10-21T06:44:56Z

Thanks for the feedback @artembilan! Two questions:

Yes, I agree that it can be renamed to the MESSAGE_CONTENT, but do we really always going to have it as String? Are you anticipating it as a CLOB in standard DBs and some custom type in specific, but that still would not be byte[]?

1. Column Naming

You mentioned MESSAGE_CONTENT is more semantic. Should I rename(schema-(db).sql file) it?

Is it okay with a breaking change for better naming? Or keep MESSAGE_BYTES?

2. Type-Safe Reading

Current getString() works for PostgreSQL/MySQL/H2. Do you mean we should add defensive handling for cases like:

java.sql.Clob (Oracle, large data)
PGobject (PostgreSQL specifics)
byte[] fallback

artembilan · 2025-10-21T12:03:32Z

I wonder if that could be kept as MESSAGE_BYTES and suggest any other name instead for JSON handling .
Might be the case that we would need to adjust our queries to avoid hard-coded name.
I believe with modern RDBMS drivers the getString() works well with CLOB.
We do have a Testcontainet for Oracle to check how JSON could be handled over there .

it is unfortunate that you are contributing this too late in the current 7.0 generation.
We do RC1 today which means we don’t have enough time to make your contribution as great. After that it is a code freeze and we won’t be able to rename column until version 8.0.
Either way I think MESSAGE_BYTES still makes sense and for JSON it could be anything else . We just need to double check the code for that naming usage.

artembilan

OK. I think we are on the right track, but still need dedicate more thinking on this.
I will aim this for the next 7.1.
Meanwhile I'll make a small (well, it is going to be big by the amount of code affected 😉 ) breaking change for the today's 7.0.0-RC1 - the last chance where we can do that.
The change would be from MESSAGE_BYTES to MESSAGE_CONTENT.
This will be a good foundation for your work over here.

Thank you!

artembilan · 2025-10-21T15:10:17Z

Here you are: #10524!

yybmion · 2025-10-22T15:05:22Z

@artembilan Thanks for the detailed explanation and for taking on the naming change PR.

I’m updating the PR per your review.

I think we should drop all of these extra schema scripts and just document how to change the target RDBMS to support JSON serialization instead.

I understand your point about simplifying the schemas and documenting JSON serialization setup instead.
However, for testing purposes, I still think having a dedicated table or script for verifying JSON results would be helpful.

What do you think about keeping a lightweight schema just for the tests (under src/test/resources)?

artembilan · 2025-10-22T15:07:58Z

What do you think about keeping a lightweight schema just for the tests (under src/test/resources)?

That totally makes sense.
And exactly this one could go to the doc as an example what exactly has to be done in the target RDBMS to support JSON.

- Add JacksonChannelMessageStorePreparedStatementSetter for serialization - Add JacksonMessageRowMapper for deserialization with trusted package validation - Support PostgreSQL (JSONB), MySQL (JSON), and H2 (CLOB) databases - Add comprehensive test coverage and documentation Fixes: spring-projectsgh-9312 Signed-off-by: Yoobin Yoon <yunyubin54@gmail.com>

yybmion · 2025-10-23T14:59:54Z

Thanks for feedback @artembilan!

I’ve updated the code based on the review for c1d0b32.

artembilan · 2025-10-23T15:05:28Z

I’ve updated the code based on the review

Thank you @yybmion !

But as I said before: we cannot accept a new code into the current 7.0.0 milestone since at this moment it is called "code freeze" .
The we would have one more month of 7.0.1 patch release fixing bugs.
And only after that we are going to switch to 7.1.0 where we can accept new features.

Does that make sense to you?

yybmion · 2025-10-23T15:16:30Z

Thank you for the explanation @artembilan !

Yes, I completely understand the release schedule.

Please let me know if there are any updates or changes needed before the merge.

Thanks again for your guidance throughout the review process!

yybmion force-pushed the gh-9312 branch from 723889c to 202e96d Compare October 18, 2025 15:31

artembilan requested changes Oct 20, 2025

View reviewed changes

artembilan requested changes Oct 21, 2025

View reviewed changes

yybmion force-pushed the gh-9312 branch from 202e96d to 38f850d Compare October 23, 2025 14:41

yybmion force-pushed the gh-9312 branch from 38f850d to c1d0b32 Compare October 23, 2025 14:54

Add Jackson JSON serialization for JdbcChannelMessageStore #10508

Are you sure you want to change the base?

Add Jackson JSON serialization for JdbcChannelMessageStore #10508

Uh oh!

Conversation

yybmion commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yybmion commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

1. Column naming: MESSAGE_BYTES or MESSAGE_CONTENT.

2. Database coverage: PostgreSQL, MySQL, H2 only

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!

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!

yybmion commented Oct 21, 2025

1. Column Naming

2. Type-Safe Reading

Uh oh!

artembilan commented Oct 21, 2025

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

artembilan commented Oct 21, 2025

Uh oh!

yybmion commented Oct 22, 2025

Uh oh!

artembilan commented Oct 22, 2025

Uh oh!

yybmion commented Oct 23, 2025

Uh oh!

artembilan commented Oct 23, 2025

Uh oh!

yybmion commented Oct 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yybmion commented Oct 18, 2025 •

edited

Loading

yybmion commented Oct 18, 2025 •

edited

Loading

1. Column naming: `MESSAGE_BYTES` or `MESSAGE_CONTENT`.