XStream

Improve XStream's setClassLoader() method

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.3
  • Fix Version/s: 1.3.1
  • Component/s: Core
  • Labels:
    None

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

Hide
Mindaugas Žakšauskas added a comment -

Have to correct myself a bit: the second code snippet wouldn't work either.

The way to make it work is:

Xstream x1 = new XStream();
x1.setClassLoader( someClassloader );
x1.processAnnotations( MyClass.class );

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.

Show
Mindaugas Žakšauskas added a comment - Have to correct myself a bit: the second code snippet wouldn't work either. The way to make it work is:
Xstream x1 = new XStream(); x1.setClassLoader( someClassloader ); x1.processAnnotations( MyClass.class );
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.
Hide
Joerg 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.

Show
Joerg 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.
Hide
Joerg 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.

Show
Joerg 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.
Hide
Joerg Schaible added a comment -

Set correct fix version.

Show
Joerg Schaible added a comment - Set correct fix version.
Hide
Joerg Schaible added a comment -

Fixed for upcoming release.

Show
Joerg Schaible added a comment - Fixed for upcoming release.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: