Add serialVersionUID to MessageHistory

[onobc]

@artembilan not sure what test to add for this one. We could do this:

• Serialize a 5.1 MessageHistory to disk.
• Put that file in test/resources
• Deserialize the file w/ the latest MessageHIistory.
  I'm not sure if this is worth adding to automation though. It is somewhat a one-off and should not be an issue again in this class.

Fixes gh-3737

[artembilan]

Yes, I agree it is pointless to waste our time figuring out how to test it in JUnit.

It is really would be enough to test it once.
We may just accept this PR and merge.
And then ask @german22 to test his project against latest 5.5.10-SNAPSHOT.

Just check the project and other similar entities are OK, even if they just only have serialVersionUID = 1L.

Although I feel as we have to add an explicit one to all the ApplicationEvent impls, and exceptions, like ReplyRequiredException...

WDYT?

[artembilan]

After removing that suppression we got now this:

/home/runner/work/spring-integration/spring-integration/spring-integration-core/src/main/java/org/springframework/integration/history/MessageHistory.java:312: warning: [serial] serializable class Entry has no definition of serialVersionUID
	public static class Entry extends Properties {
	              ^

So, it has to be fixed with an explicit (extracted) serialVersionUID as well.

[artembilan]

We are not ready to merge this yet.
Even if this will fix data stored from the 5.5.1.
But what about the data stored already starting with 5.5.2?

We have to come up somehow with a solution which could deal with old and new class versions...

[artembilan]

That's great, @onobc !

But I believe we should leave such a workaround outside of the framework code even for the current version we are going to fix it for.

Better to have a single workaround class (even with that VersionTolerantObjectInputStream as nested) and show it in the issue for end-user.

The fix has to be like an explicit for the current MessageHistory class version - serialVersionUID = -2340400235574314134L.

So, it is not going to be a break point in the next 6.0.

(I don't think we will migrate a MessageHistory to the record as IDE suggests...)

[onobc]

That's great, @onobc !

But I believe we should leave such a workaround outside of the framework code even for the current version we are going to fix it for.

Better to have a single workaround class (even with that VersionTolerantObjectInputStream as nested) and show it in the issue for end-user.

Sounds good @artembilan . Yep, I was not wanting to actually merge it in - but figure out where to put it. The docs idea in a single class sounds good. I will put it in a branch locally (just to keep around for later if needed), consolidate it into single class, and produce a HowTo in the issue w/ the code sample.

I will close this PR once I update the issue w/ the sample code.

The fix has to be like an explicit for the current MessageHistory class version - serialVersionUID = -2340400235574314134L.

Yep, that was in the javadoc at the top of the deserializer on how to use. I will make it clear in the issue when I comment.

So, it is not going to be a break point in the next 6.0.

(I don't think we will migrate a MessageHistory to the record as IDE suggests...)

Yeh - no changes to framework should come out of this PR at all.

[artembilan]

I mean, Chris, that current MessageHistory has to got that serialVersionUID = -2340400235574314134L. And that's exactly what we will merge and back-port.
It is not going to be a breaking change at all: just will let us to avoid similar issue in the future when we would change something in the MessageHistory breaking its class version.

[onobc]

I mean, Chris, that current MessageHistory has to got that serialVersionUID = -2340400235574314134L. And that's exactly what we will merge and back-port. It is not going to be a breaking change at all: just will let us to avoid similar issue in the future when we would change something in the MessageHistory breaking its class version.

Ahh yeh. Makes sense. Explicitly set the serialVersionUID in MH. I will amend this PR to do that.

[onobc]

Ignore the latest commits. I intended those to a separate branch for safe-keeping. I will clean this up shortly.

[onobc]

cbono@cbono-a01 server-main % serialver -classpath spring-context-5.3.14.jar:spring-context-support-5.3.14.jar:spring-core-5.3.14.jar:spring-integration-core-5.5.8-SNAPSHOT.jar:spring-jcl-5.3.14.jar:spring-messaging-5.3.14.jar org.springframework.integration.history.MessageHistory
org.springframework.integration.history.MessageHistory:    private static final long serialVersionUID = -2340400235574314134L;

[onobc]

cbono@cbono-a01 server-main % serialver -classpath spring-context-5.3.14.jar:spring-context-support-5.3.14.jar:spring-core-5.3.14.jar:spring-integration-core-5.5.8-SNAPSHOT.jar:spring-jcl-5.3.14.jar:spring-messaging-5.3.14.jar org.springframework.integration.history.MessageHistory.Entry
org.springframework.integration.history.MessageHistory.Entry:    private static final long serialVersionUID = -8225834391885601079L;

[artembilan]

... and cherry-picked to 5.5.x.

Thanks, @onobc ; looking forward for more!