Details
Bug
Closed
Minor
Description
The setClassLoader() method is supposed to allow to pass the custom classloader to the XStream object.
However, if, for example, you use it for XML to object serialization it is already too late. Speaking in Java, the following code:
XStream x1 = new XStream();
x1.setClassloader( someClassloader );
x1.fromXML( someInputStream );
will result com.thoughtworks.xstream.mapper.CannotResolveClassException if, the XStream class is loaded with the different classloader than the one referenced in the XML.
The following code would just work fine:
XStream x1 = new XStream( null, null, someClassloader );
x1.fromXML( someInputStream );
This is most likely because of setupAliases() which is called from within the constructor would look for annotations and those annotations would not be reachable at the time of XStream object creation (see the first use case).
The setClassLoader() method should either provide warning in its Javadoc or reinit internal XStream state.
Activity
Sorry, but your assumptions 
are simply not true.
As a fact I can admit that some settings will cause a specific class type (loaded by a classloader) is kept as part of this configuration. However, all "auto-configuration" done during construction phase is normally only done for classes available as part of the JDK (well, there are exceptions - therefore this report has a point) that should not have any influence on a new classloader. And especially annotations are not processed at all.
Therefore it might be best to describe your problem on the user's list where we can have a closer look and an analysis what's going wrong and why.
Jörg Schaible
added a comment - Sorry, but your assumptions are simply not true.
As a fact I can admit that some settings will cause a specific class type (loaded by a classloader) is kept as part of this configuration. However, all "auto-configuration" done during construction phase is normally only done for classes available as part of the JDK (well, there are exceptions - therefore this report has a point) that should not have any influence on a new classloader. And especially annotations are not processed at all.
Therefore it might be best to describe your problem on the user's list where we can have a closer look and an analysis what's going wrong and why. I checked the initialization and removed any converter that triggers a class not available in the JDK or XStream itself. This means especially no implicit support for CGLIB proxies anymore. FAQ and release notes have been updated. An additional note has been added to the javadoc of XStream.setClassLoader.
Jörg Schaible
added a comment - I checked the initialization and removed any converter that triggers a class not available in the JDK or XStream itself. This means especially no implicit support for CGLIB proxies anymore. FAQ and release notes have been updated. An additional note has been added to the javadoc of XStream.setClassLoader. Set correct fix version.
Jörg Schaible
added a comment - Set correct fix version. Fixed for upcoming release.
Jörg Schaible
added a comment - Fixed for upcoming release. 
Have to correct myself a bit: the second code snippet wouldn't work either.
The way to make it work is:
This is simple enough if only one class is annotated, however quite cumbersome and not scalable if there are more.
Above said, the XStream::autodetectAnnotations( boolean ) method isn't much useful as one needs to go over processAnnotations( Class clazz ); and it resets the flag to true automatically anyway.
I think this has at least to be better documented in the Javadoc.