Fix concurrency issues in XStreamMarshaller

[JakobFels]

Just stumbled on a nasty concurrency issue in org.springframework.oxm.xstream.XStreamMarshaller.

When you forget to call afterPropertiesSet on this marshaller, the internally held XStream instance will not be initialized. Instead, it will be done in the method getXStream, which is called from both marshal and unmarshal methods.

This initialization is not guarded, and might happen concurrently. In this case, the ConverterLookup used to store converters will be shared by the XStream instances that are constructed, which can lead to strange application behaviour, since the underlying data structure is not thread safe.

In our application, it lead to very strange errors during XML marshalling/unmarshalling, since a couple of converters were missing. This happened whenever our app process scaled up during high load.

I see 2 possible solutions:

• throw an exception in case afterPropertiesSet is not called on an instance
• make XStream initialization thread safe

Spring version affected is 5.2.5.RELEASE

[sbrannen]

Thanks for raising the issue.

We'd not want to start throwing an exception here, since that might break existing use cases that did not encounter concurrency issues.

Rather, we'll introduce some locking for that field to avoid concurrency issues.

[sbrannen]

This has been addressed in ce11fdf for the upcoming Spring Framework 5.2.7 release.

Feel free to try it out in the next 5.2.7 snapshot and provide feedback.

[sbrannen]

Reopening to make use of the SingletonSupplier. See ce11fdf#r39003837 for details.