|
It's a lot more than just a new name. Look at the acceptance test for collections and you know, what I mean.
Is there a known workaround for this problem?
We are currently using XStream to serialize a custom object containing two private variables: private String name; After upgrading to Java 1.5 those objects can not be restored and the following exception is thrown: com.thoughtworks.xstream.converters.ConversionException: Cannot construct java.util.Collections$SynchronizedRandomAccessList: java.util.Collections$SynchronizedRandomAccessList I had a look at the issue and the problem is, that the synchronized collections in JDK 1.5 use a custom serialization, while they don't have this in JDK 1.4. This leads unfortunately to a complete different XML representation. Please try this as workaround:
final Class synchronizedRandomAccessList = Class.forName("java.util.Collections$SynchronizedRandomAccessList");
xstream.register(
new ReflectionConverter(xstream.getMapper(), new JVM().bestReflectionProvider()) {
public boolean canConvert(Class type) {
return type == synchronizedRandomAccessList;
}
});
Andreas
I think you have to reconsider your design, because xstream with reflection converter does not provide cross version compatibility. U dont probably use jdk 1.3, but you should know that Vector class is not compatible between version 1.3 and 1.4 Joerg,
is there any update on this? I'm serializing object between a servlet and an applet, and I cannot guarantee for the same version of Java on both sides. I have to transfer a list of objects, and I wonder about alternatives. Sounds like the whole idea of xstream would not work for an applet? Tnx, M Matthias, please ask questions on the user list. Depending on your use case, you have different options.
|
|||||||||||||||||||||||||||||||||||||||
Something like:
xstream.alias("java.util.Collections-SynchronizedList", Class.forName("java.util.Collections$SynchronizedRandomAccessList"));
Will force XStream to write SynchronizedRandomAccessList as SynchronizedList. Depending which way you are going, you may need to do the opposite.
If this approach doesn't work, you will probably have to either create a custom Converter implementation that automatically does the migration or perform some pre/post processing on the XML to alter it.