Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Cannot Reproduce
-
Affects Version/s: 1.1.3
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
-
JDK version and platform:jdk1.5.0_15
Description
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother fails to convert an object from textual data (ConversionException) because the mapper cannot locate the appropriate class for an elemen - default (CannotResolveClassException)..
This fragment <javax.xml.namespace.QName>
<default>... of the xml (attached here) is not being parsed properly.. and I get the following error ...
Caused by: com.thoughtworks.xstream.converters.ConversionException: default : default
*
o
+ Debugging information ----
required-type : javax.xml.namespace.QName
cause-message : default : default
class : com.jackbe.jbp.sas.rds.infomodel.impl.ServiceImplSerializedPart
message : default : default
path : /com.jackbe.jbp.sas.rds.infomodel.impl.ServiceImplSerializedPart/serviceBinding/com.jackbe.jbp.sas.rds.infomodel.wsdl.impl.SoapServiceBi
ndingImpl/default/operationBindings/entry/com.jackbe.jbp.sas.rds.infomodel.wsdl.impl.SoapOperationBindingImpl/com.jackbe.jbp.sas.rds.infomodel.wsdl.impl.SoapO
perationBindingImpl/default/inputMessage/com.jackbe.jbp.sas.rds.infomodel.wsdl.impl.SoapOperationMessageImpl/default/messageName/javax.xml.namespace.QName/def
ault
cause-exception : com.thoughtworks.xstream.alias.CannotResolveClassException
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:45)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.reflection.ReflectionConverter.unmarshal(ReflectionConverter.java:103)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter$2.defaultReadObject(SerializableConverter.java:330)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter.unmarshal(SerializableConverter.java:363)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter$2.defaultReadObject(SerializableConverter.java:330)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter.unmarshal(SerializableConverter.java:363)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:82)
at com.thoughtworks.xstream.converters.collections.MapConverter.populateMap(MapConverter.java:72)
at com.thoughtworks.xstream.converters.collections.MapConverter.unmarshal(MapConverter.java:59)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter$2.defaultReadObject(SerializableConverter.java:330)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter.unmarshal(SerializableConverter.java:363)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.converters.reflection.ReflectionConverter.unmarshal(ReflectionConverter.java:103)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:38)
at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:39)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:99)
at com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy.unmarshal(ReferenceByXPathMarshallingStrategy.java:12)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:552)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:540)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:490)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:483)
-
-
-
- Its a major show-stopper for me, any immediate help will be higle appreciated
-
-
Activity
I had the same problem. I can quantify what's going on, for posterity. And help you figure out what is going on as well.
On my system, Java's version of this class is in jar:file:/C:/apps/jdk1.6.0/jre/lib/rt.jar!/javax/xml/namespace/QName.class.
There are also versions, that is, classes of the same name and package, in:
- xml-apis-1.3.04.jar
- jaxp-api-1.3.jar
- jaxrpc-1.1.jar
- stax-api-1.0.1.jar
Because of an unrelated issue, I had xml-apis in my endorsed folder. This resulted in the standard Java 6 class being used in one JVM and the xml-apis class being used in another.
The standard Java6 class serializes to:
<?xml version="1.0" ?><javax.xml.namespace.QName><namespaceURI>http://www.infotrustgroup.com/tests</namespaceURI><localPart>test</localPart><prefix></prefix></javax.xml.namespace.QName>
The xml-apis class apparently implements a custom serializer, so it serializes differently:
<?xml version="1.0" ?><javax.xml.namespace.QName serialization="custom"><javax.xml.namespace.QName><default><localPart>test</localPart><namespaceURI>http://www.infotrustgroup.com/tests</namespaceURI><prefix></prefix></default></javax.xml.namespace.QName></javax.xml.namespace.QName>
The following code will uncover all the different versions of javax.xml.namespace.QName available to your classloader. Of course, the one at the top of the list is the one that is actually being used.
try
{
Enumeration<URL> enu = getClass().getClassLoader().getResources("javax/xml/namespace/QName.class");
while(enu.hasMoreElements())
}
catch(Exception e)
There is nothing you can do about this from an XStream perspective, except avoid QName serialization altogether. At least, though, we know why this is happening. And maybe this comment will help someone else avoid an entire day troubleshooting this problem.
Jason Smith
added a comment - I had the same problem. I can quantify what's going on, for posterity. And help you figure out what is going on as well.
On my system, Java's version of this class is in jar: file:/C:/apps/jdk1.6.0/jre/lib/rt.jar!/javax/xml/namespace/QName.class .
There are also versions, that is, classes of the same name and package, in:
xml-apis-1.3.04.jar
jaxp-api-1.3.jar
jaxrpc-1.1.jar
stax-api-1.0.1.jar
Because of an unrelated issue, I had xml-apis in my endorsed folder. This resulted in the standard Java 6 class being used in one JVM and the xml-apis class being used in another.
The standard Java6 class serializes to:
<?xml version="1.0" ?><javax.xml.namespace.QName><namespaceURI> http://www.infotrustgroup.com/tests </namespaceURI><localPart>test</localPart><prefix></prefix></javax.xml.namespace.QName>
The xml-apis class apparently implements a custom serializer, so it serializes differently:
<?xml version="1.0" ?><javax.xml.namespace.QName serialization="custom"><javax.xml.namespace.QName><default><localPart>test</localPart><namespaceURI> http://www.infotrustgroup.com/tests </namespaceURI><prefix></prefix></default></javax.xml.namespace.QName></javax.xml.namespace.QName>
The following code will uncover all the different versions of javax.xml.namespace.QName available to your classloader. Of course, the one at the top of the list is the one that is actually being used.
try
{
Enumeration<URL> enu = getClass().getClassLoader().getResources("javax/xml/namespace/QName.class");
while(enu.hasMoreElements())
{
System.out.println(enu.nextElement());
}
}
catch(Exception e)
{
throw new RuntimeException(e);
}
There is nothing you can do about this from an XStream perspective, except avoid QName serialization altogether. At least, though, we know why this is happening. And maybe this comment will help someone else avoid an entire day troubleshooting this problem. @Jason, what you can always do is to write a custom converter for QName.
Jörg Schaible
added a comment - @Jason, what you can always do is to write a custom converter for QName. 
You are using different implementations for QName. Please use the user's list for further questions.