Spring XStreamMarshaller should avoid direct use of CompositeClassLoader which is not exported by XStream in OSGi

XStreamMarshaller uses the class CompositeClassLoader here, but it is not part of the public API. xstream is an OSGi bundle and does not export the package com.thoughtworks.xstream.core.util. This results in a ClassNotFoundException when using Spring oxm + xstream in an OSGi environment since that package is not exported.

I've asked explicitly here about this. Could Spring oxm use the same classloader which loaded the xstream classes (XStream.class.getClassLoader()) to lookup the CompositeClassLoader and create a new instance to avoid this issue?

Comment From: jhoeller

Since this is just a default instance for our beanClassLoader field which gets overridden in any common Spring setup anyway (to Spring's context-level ClassLoader as propagated through BeanClassLoaderAware), I see no need to hang on to CompositeClassLoader there. We can simply use ClassUtils.getDefaultClassLoader() as the default value (which will only apply for testing scenarios and other custom use of XStreamMarshaller outside of a Spring container) like we do in other places.