ServerSerialisers static init should change Serialisers primitive lookup strategy

[franz1981]

Fixes #37776

[franz1981]

@geoand this is weird (meaning that I wasn't expecting this dependency, but reading the code twice was clear!): this is really the expected behaviour?

eg

1. ClientSerialisers is used and no primitive wrappers lookup happen
2. ServerSerialisers is now used as well
3. both ServerSerialisers and ClientSerialisers start to lookup primitive types

Maybe this is just a non possible situation, and everything always happen in a single thread, and in a given order.
In that case I can remove the volatile keyword or we can move this "setup" in who will make these classes to be loaded
and can "configure" them in order that when ServerSerialisers is configured, all the serializers behave the same.

[geoand]

I haven't debugged yet, but my guess is that ClientSerializers are now wrong, as opposed to the case before the change

[franz1981]

@geoand

as opposed to the case before the change

I've restored the "original" behaviour (before #37655) with this one
ie static init of SerialSerialisers influence the behaviour of all Serialisers's son.

If the original behaviour need to be changed for the case of #37778 (comment) let me know and i'll put it in draft, awaiting a different fix on monday - I don't think we're in hurry (it's nearly weekend :P)

[geoand]

To be honest, we always need the primitive lookup.

You could have only the client part without the server but that still needs to work with primitives

[quarkus-bot]

Failing Jobs - Building 39d3475

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	Native Tests - Amazon	Update Docker Client User Agent	⚠️ Check →	Logs	Raw logs	🚧
✖	Native Tests - Data2	Update Docker Client User Agent	⚠️ Check →	Logs	Raw logs	🚧
✖	Native Tests - Data3	Update Docker Client User Agent	⚠️ Check →	Logs	Raw logs	🚧

[geoand]

@franz1981 thanks for this, but I actually prefer #37788 since its is more correct and also contains a test.