Details
-
Type:
Bug
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.2
-
Component/s: None
-
Labels:None
Description
XStream seems to have trouble with CGLIB proxies based on real classes. See following effect for a proxy extending HashMap, where the ObjectName element gets lost, that is stored in the HashMap of the DelegatingHandler:
public class DelegatingHandler implements InvocationHandler, Serializable {
private final Object delegate;
public DelegatingHandler(Object delegate)
{ this.delegate = delegate; }public Object invoke(Object obj, Method method, Object[] args) throws Throwable
{ return method.invoke(delegate, args); }}
/**
- @throws Exception
*/
public void testCGLib() throws ExceptionUnknown macro: { final Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(HashMap.class); enhancer.setInterfaces(new Class[]{Map.class}); enhancer.setCallback(new DelegatingHandler(new HashMap())); final Map orig = (Map)enhancer.create(); orig.put("ObjectName", new ObjectName("domain}
Issue Links
Activity
A workaround for the above case is a Converter for CGLIB proxies, that skips the SerializationConverter. In the sample a modified ReflectionConverter is registered with a higher priority, that handles all CGLIB-based proxies.
xstream.registerConverter(new ReflectionConverter(xstream.getMapper(), new JVM().bestReflectionProvider()){
public boolean canConvert(Class type)
});
Note: It is not yet clear if this handles all the CGLIB proxy problems. Some proxies might not be initializable anymore, others have writeReplace and readResolve methods, that can/will have additionally effects.
Jörg Schaible
added a comment - A workaround for the above case is a Converter for CGLIB proxies, that skips the SerializationConverter. In the sample a modified ReflectionConverter is registered with a higher priority, that handles all CGLIB-based proxies.
xstream.registerConverter(new ReflectionConverter(xstream.getMapper(), new JVM().bestReflectionProvider()){
public boolean canConvert(Class type)
{
return Factory.class.isAssignableFrom(type);
}
});
Note: It is not yet clear if this handles all the CGLIB proxy problems. Some proxies might not be initializable anymore, others have writeReplace and readResolve methods, that can/will have additionally effects. Next chapter: The workaround in the last comment is only valid for the current process. If another process tries to deserialize the stream, the CGLIB proxy classes are no longer known. A combination of Mapper and Converter is necessary, although it is not yet clear if such a proxy can be properly recreated at all.
Jörg Schaible
added a comment - Next chapter: The workaround in the last comment is only valid for the current process. If another process tries to deserialize the stream, the CGLIB proxy classes are no longer known. A combination of Mapper and Converter is necessary, although it is not yet clear if such a proxy can be properly recreated at all. Support for the CGLIB Enhancer has been added. Supported is limited to Enhancer created proxies using CGLIB's DefaultNamingStrategy, no super class or a superclass with an accessible default constructor and a single Callback.
Jörg Schaible
added a comment - Support for the CGLIB Enhancer has been added. Supported is limited to Enhancer created proxies using CGLIB's DefaultNamingStrategy, no super class or a superclass with an accessible default constructor and a single Callback. I guess the limitation for single callback can be removed in cases where the 2nd callback is null (e.g. for hibernate lazy loaded classes) . see - http://jira.codehaus.org/browse/XSTR-423 for more.
Shahiduzzaman
added a comment - I guess the limitation for single callback can be removed in cases where the 2nd callback is null (e.g. for hibernate lazy loaded classes) . see - http://jira.codehaus.org/browse/XSTR-423 for more. 
A really bad coincidence happen for CGLIB proxies of real classes. A CGLIB class proxy will delegate all method calls, but represents still a complete instance of the original class. If this class is Serializable and has a readObject/writeObject methods two things may happen:
a) any direct access to a field will reference the element in the proxied instance
b) any indirect access will be delegated by the proxy
This may leed to the situation, that the values written into the stream might be from different objects.
In the above case the proxied HashMap writes a size of 0 into the stream and writes afterwards the elements of the delegate. Since those elements are written again later, XStream creates a reference. Unfortunately the readObject method of the HashMap will recognize, that it has no elements and just skip all the written values ... and all references will suddenly point to nothing.