[XSTR-654] Unmarshall fails if there's an alias same as the value of an implicitCollection

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 1.4
Component/s: None
Labels:
None

Description

For example:

package com.test;
public class Foo

{ List<Entry> entry; ... }

package com.test;
public class Entry

{ String prop; ... }

Then I add alias and an implictCollection
XStream xs = new XStream();
xs.alias("foo", com.test.Foo.class);
xs.alias("entry", com.test.Entry.class);

xs.addImplicitCollection(com.test.Foo.class, "entry");

When marshalling, it returns the xml as expected without the needless root <entry> element:
something like:
<foo>
<entry>
<prop>123</prop>
</entry>
<entry>
<prop>123</prop>
</entry>
</foo>

But, when unmarshalling from xml like above, it fails.

Exception in thread "main" com.thoughtworks.xstream.converters.ConversionException: prop: prop: prop: prop
---- Debugging information ----
message : prop: prop
cause-exception : com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message : prop: prop
class : com.test.Foo
required-type : java.lang.Object
path : /foo/entry/prop
line number : 4
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:89)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:225)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:246)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:218)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:923)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:909)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:853)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:845)
at com.covisint.healthcare.cdr.CdrWrapperMirthUtils.main(CdrWrapperMirthUtils.java:72)
Caused by: com.thoughtworks.xstream.mapper.CannotResolveClassException: prop: prop
at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:68)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:71)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:86)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:96)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:52)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.determineType(AbstractReflectionConverter.java:347)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:208)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
... 22 more

Activity

Hide

Permalink

Jörg Schaible added a comment - 30/May/11 6:52 AM

Your XStream setup is simply ambiguous. At deserialization time it will always prioritize fields with the same name. You may configure an explicit alias for the field to resolve the ambiguity.

Show

Jörg Schaible added a comment - 30/May/11 6:52 AM Your XStream setup is simply ambiguous. At deserialization time it will always prioritize fields with the same name. You may configure an explicit alias for the field to resolve the ambiguity.

Hide

Permalink

Grant added a comment - 30/May/11 8:39 PM

Hi Joerg,
You mean adding an alias for the implicitCollection field, like:
xs.aliasField("entryAlias", com.test.Foo.class, "entry"); ?
But it does no help...

I'm just thinking XStream should be able to infer that the <entry> node doesn't represent the entry field in Foo because the field is an implicit collection. Do you think so?

Show

Grant added a comment - 30/May/11 8:39 PM Hi Joerg, You mean adding an alias for the implicitCollection field, like: xs.aliasField("entryAlias", com.test.Foo.class, "entry"); ? But it does no help... I'm just thinking XStream should be able to infer that the <entry> node doesn't represent the entry field in Foo because the field is an implicit collection. Do you think so?

Hide

Permalink

Jörg Schaible added a comment - 02/Jun/11 12:45 PM

Hmm. I created a little unit test, but this works for me (as part of XStream's acceptance tests for implicit collections):

public static class Notes {
    List info = new ArrayList();
}

public static class Info {
    private String info;
    public Info(String info) {
        this.info = info;
    }
    public String toString() {
        return info;
    }
}

public void testCanNameImplicitElementsLikeField() throws NoSuchMethodException {
    xstream.alias("notes", Notes.class);
    xstream.addImplicitCollection(Notes.class, "info", "info", Info.class);
    xstream.registerConverter(new ToStringConverter(Info.class));
    
    Notes notes = new Notes();
    notes.info.add(new Info( "joe did it"));
    notes.info.add(new Info("joehni did it"));
    
    String expected = "" +
    "<notes>\n" +
    "  <info>joe did it</info>\n" +
    "  <info>joehni did it</info>\n" +
    "</notes>";

    assertBothWays(notes, expected);
}

Show

Jörg Schaible added a comment - 02/Jun/11 12:45 PM Hmm. I created a little unit test, but this works for me (as part of XStream's acceptance tests for implicit collections): public static class Notes { List info = new ArrayList(); } public static class Info { private String info; public Info(String info) { this.info = info; } public String toString() { return info; } } public void testCanNameImplicitElementsLikeField() throws NoSuchMethodException { xstream.alias("notes", Notes.class); xstream.addImplicitCollection(Notes.class, "info", "info", Info.class); xstream.registerConverter(new ToStringConverter(Info.class)); Notes notes = new Notes(); notes.info.add(new Info( "joe did it")); notes.info.add(new Info("joehni did it")); String expected = "" + "<notes>\n" + " <info>joe did it</info>\n" + " <info>joehni did it</info>\n" + "</notes>"; assertBothWays(notes, expected); }

Hide

Permalink

Grant added a comment - 02/Jun/11 9:30 PM

Hi Joerg,
Thank you for your suggestion and example.
The "addImplicitCollection(Class ownerType, String fieldName, String itemFieldName, Class itemType)" instead of "addImplicitCollection(Class ownerType, String fieldName)" can be a workaround, but not for me.
Actually I haven't direct access to XStream. I'm using org.springframework.oxm.xstream.XStreamMarshaller, a marshaller which is provided by spring framework(version 3.0.5) to integrate XStream. But unfortunately, it only supports the method "addImplicitCollection(Class ownerType, String fieldName)"...
At last, I found another workaround, adding a staxDriver and qname mapping on the list item type class(in my example, it's com.test.Entry) and deleting the alias for this class. Don't know why but it works...and I get some namespace supports.
I don't know it should be Spring or XStream to improve its ability. But I do think XStream can do better if possible, on detecting potential conflicts and providing more detailed debug information.
Thank you for paying attention to the issue!

Show

Grant added a comment - 02/Jun/11 9:30 PM Hi Joerg, Thank you for your suggestion and example. The "addImplicitCollection(Class ownerType, String fieldName, String itemFieldName, Class itemType)" instead of "addImplicitCollection(Class ownerType, String fieldName)" can be a workaround, but not for me. Actually I haven't direct access to XStream. I'm using org.springframework.oxm.xstream.XStreamMarshaller, a marshaller which is provided by spring framework(version 3.0.5) to integrate XStream. But unfortunately, it only supports the method "addImplicitCollection(Class ownerType, String fieldName)"... At last, I found another workaround, adding a staxDriver and qname mapping on the list item type class(in my example, it's com.test.Entry) and deleting the alias for this class. Don't know why but it works...and I get some namespace supports. I don't know it should be Spring or XStream to improve its ability. But I do think XStream can do better if possible, on detecting potential conflicts and providing more detailed debug information. Thank you for paying attention to the issue!

Hide

Permalink

Jörg Schaible added a comment - 05/Jul/11 7:18 PM

I fixed this now also when using the method with two arguments. The problem basically arose there when one of the elements of the collection had the same name as the field of the imlicit collection itself.

Show

Jörg Schaible added a comment - 05/Jul/11 7:18 PM I fixed this now also when using the method with two arguments. The problem basically arose there when one of the elements of the collection had the same name as the field of the imlicit collection itself.

People

Assignee:

Jörg Schaible

Reporter:

Grant

Votes:

0 Vote for this issue

Watchers:

0 Start watching this issue

Dates

Created:

30/May/11 4:39 AM

Updated:

05/Aug/11 5:04 PM

Resolved:

05/Jul/11 7:18 PM