Fix typo in message ID generation section

[mjd507]

No description provided.

[mjd507]

I have a doubt

The idGenerator field in MessageHeaders looks always null, and no static setIdGenerator method provided.

but the static getGenerator method will check this null idGenerator first, then the default-idGenerator.

I see in spring integration, our IdGeneratorConfigurer will use reflection to set this idGenerator field.

is it intentional, what's the harm if we add a static setIdGenerator method.

[artembilan]

what's the harm if we add a static setIdGenerator method.

That is totally different story from what you have just fixed here.
I cannot answer you to that question because that was done before me.
You can raise a GH issue in the https://github.com/spring-projects/spring-framework with that question and proposal.
Doesn't look like it really comes with the harm: if we can do that via reflection, that means users of the framework can do that, too.

[rstoyanchev]

The question comes back here actually. The idGenerator was added while MessageHeaders was still in Spring Integration with #5889.

[artembilan]

Hi @rstoyanchev !

Sorry for looping you in.
Looks like this commit has changed external settings decision in favor of reflection: 74f57c1.
Points to the same issue and doesn't say too much.

We may ask @olegz on the matter if he can recall team discussion on the matter.

But mostly the question is: what kind of harm do we see letting the static setter to be called instead of reflection?

Thanks

[artembilan]

Hey, @rstoyanchev !

Had a chat with @olegz and he is OK with changing reflection back to the static setter in the MessageHeaders.

The general idea behind moving to the reflection way was to hide message ids manipulation as much as possible.
And the point is that message ID has to be as unique as possible therefore this idGenerator is used as static property in the MessageHeaders independently how messages are created.

Let me know if you are OK making that change in the MessageHeaders with respective warning in its Javadoc!
We then do something similar in our IdGeneratorConfigurer and docs.

Thank you!

[rstoyanchev]

@artembilan certainly we can consider some sort of improvement.