Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.3.1
-
Fix Version/s: 1.4.5
-
Component/s: Converters
-
Labels:None
-
JDK version and platform:Sun 1.5.0_18 for Windows
Description
JavaClassConverter does not use the class aliasing mapper. It writes and reads non-aliased class names. Example:
public class C1 implements Serializable {
private static final long serialVersionUID = 1L;
}
public class C2 implements Serializable {
static private final long serialVersionUID = 1L;
public HashMap<Class<?>, Integer> f = new HashMap<Class<?>, Integer>();
public C2()
{ f.put(C1.class, Integer.valueOf(1)); }}
public class Test {
public static void main(String[] args) throws IOException
public static void serialize(XStream xstream, File file) throws IOException {
C2 c2 = new C2();
OutputStream os = new FileOutputStream(file);
try
{ xstream.toXML(c2, os); }finally
{ os.close(); } }
}
writes
<a2>
<f>
<entry>
<java-class>javaClass.C1</java-class>
<int>1</int>
</entry>
</f>
</a2>
and not
<a2>
<f>
<entry>
<java-class>javaClass.a1</java-class>
<int>1</int>
</entry>
</f>
</a2>
Issue Links
Activity
Thank you for your explanations. I run the following adaptation of the example:
XStream xstream = new XStream(new DomDriver());
Class<?>[] origin =
;
String xml = xstream.toXML(origin);
System.out.println(xml);
Class<?>[] serialized = (Class[]) xstream.fromXML(xml);
System.out.println(serialized[0]);
System.out.println(serialized[1]);
With XStream 1.4.4, the output is the following:
<java-class-array>
<java-class>java.util.List</java-class>
<java-class>java.util.ArrayList</java-class>
</java-class-array>
interface java.util.List
class java.util.ArrayList
When I perform the code changes that are proposed
in http://jira.codehaus.org/browse/XSTR-731, the output is the following:
<java-class-array>
<java-class>list</java-class>
<java-class>java.util.ArrayList</java-class>
</java-class-array>
interface java.util.List
class java.util.ArrayList
That would be O.K. for me.
I use XStream to serialize objects in an installation that is obfuscated by ProGuard. Deserialization takes place in the non-obfuscated counterpart, XStream aliases being filled with the inverse of the obfuscation mapping. The obfuscation mapping guarantees uniqueness and correct handling of primitive types. Everything works fine except the handling of Java class names as mentioned here.
Till Wenzinger
added a comment - Thank you for your explanations. I run the following adaptation of the example:
XStream xstream = new XStream(new DomDriver());
Class<?>[] origin =
{List.class, ArrayList.class}
;
String xml = xstream.toXML(origin);
System.out.println(xml);
Class<?>[] serialized = (Class[]) xstream.fromXML(xml);
System.out.println(serialized [0] );
System.out.println(serialized [1] );
With XStream 1.4.4, the output is the following:
<java-class-array>
<java-class>java.util.List</java-class>
<java-class>java.util.ArrayList</java-class>
</java-class-array>
interface java.util.List
class java.util.ArrayList
When I perform the code changes that are proposed
in http://jira.codehaus.org/browse/XSTR-731 , the output is the following:
<java-class-array>
<java-class>list</java-class>
<java-class>java.util.ArrayList</java-class>
</java-class-array>
interface java.util.List
class java.util.ArrayList
That would be O.K. for me.
I use XStream to serialize objects in an installation that is obfuscated by ProGuard. Deserialization takes place in the non-obfuscated counterpart, XStream aliases being filled with the inverse of the obfuscation mapping. The obfuscation mapping guarantees uniqueness and correct handling of primitive types. Everything works fine except the handling of Java class names as mentioned here. Actually this issue is not completely resolved, because alias support for the converter is not out-of-the box.
XStream normally has no to separate between a primitive and its boxed type. The complete reflection API works always with the boxed types and converts to primitives types on the fly. However, for method and field type signatures the difference is essential. Nevertheless it is possible to register derived versions of the converters that are able to respect the aliasing with some minor effort. Following lines are taken from the AliasTest in the acceptence tests:
XStream xstream = new XStream(); Mapper mapper = new MapperWrapper(xstream.getMapper().lookupMapperOfType(ArrayMapper.class)) { public Class realClass(String elementName) { Class primitiveType = Primitives.primitiveType(elementName); return primitiveType != null ? primitiveType : super.realClass(elementName); } }; SingleValueConverter javaClassConverter = new JavaClassConverter(mapper) {}; xstream.registerConverter(javaClassConverter); xstream.registerConverter(new JavaMethodConverter(javaClassConverter){}); xstream.registerConverter(new JavaFieldConverter(javaClassConverter, mapper){});
Jörg Schaible
added a comment - - edited Actually this issue is not completely resolved, because alias support for the converter is not out-of-the box.
XStream normally has no to separate between a primitive and its boxed type. The complete reflection API works always with the boxed types and converts to primitives types on the fly. However, for method and field type signatures the difference is essential. Nevertheless it is possible to register derived versions of the converters that are able to respect the aliasing with some minor effort. Following lines are taken from the AliasTest in the acceptence tests:
XStream xstream = new XStream();
Mapper mapper = new MapperWrapper(xstream.getMapper().lookupMapperOfType(ArrayMapper.class)) {
public Class realClass( String elementName) {
Class primitiveType = Primitives.primitiveType(elementName);
return primitiveType != null ? primitiveType : super .realClass(elementName);
}
};
SingleValueConverter javaClassConverter = new JavaClassConverter(mapper) {};
xstream.registerConverter(javaClassConverter);
xstream.registerConverter( new JavaMethodConverter(javaClassConverter){});
xstream.registerConverter( new JavaFieldConverter(javaClassConverter, mapper){});
Actually this also applies to the JavaMethodConverter and JavaFieldConverter. However, it is not possible to activate this in general, because the mapping between a serialized type name and a class name is also influenced by the settings to default implementation, type aliases and XStream does here not separate between primitive types and their object counterpart (it uses the same aliases for both).
With aliasing support for these converters you would get following effect:
Class[] origin = {List.class, ArrayList.class}; String xml xstream.toXml(origin); assertEquals( "<java-class-array>\n" + " <java-class>list<java-class>\n" + " <java-class>list<java-class>\n" + "</java-class-array>" ); Class[] serialized = (Class[])xstream.fromXml(xml); assertEquals(ArrayList.class, serialized[0]); assertEquals(ArrayList.class, serialized[1]);I bet, this is not what you wanted.