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
Comment From: 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.
Comment From: sbrannen
This has been addressed in ce11fdfa801728068df7d1dfd16d4d1df38d02a1 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.
Comment From: sbrannen
Reopening to make use of the SingletonSupplier. See https://github.com/spring-projects/spring-framework/commit/ce11fdfa801728068df7d1dfd16d4d1df38d02a1#r39003837 for details.