[XSTR-737] Unable to ignore fields with predefined converters (such as <url>)

Details

Type: Bug
Status: Closed
Priority: Blocker
Resolution: Fixed
Affects Version/s: 1.x Maintenance
Fix Version/s: 1.4.5
Component/s: Core
Labels:
None

Description

In the latest trunk code, it appears it's impossible to parse XML that contains unknown elements with predefined converters, such as <url>. I tried both ignoring them the old way, by overriding shouldSerializeMember with a "definedIn != Object.class" check, or the new way, calling xStream.ignoreUnknownElements().

This is a blocker for us, because there's no workaround.

Here's a self-contained unit test to reproduce this problem with XStream 1.4.5-20130321.143015-2:

	public void testHandlingUnknownURLField() {
		final XStream xStream = new XStream();
		xStream.ignoreUnknownElements();
		xStream.processAnnotations(MyTestClass.class);
		
		final String xmlWithNewField = "<myTestClass><id>123</id><url>http://www.google.com</url></myTestClass>";
		
		final MyTestClass c1 = (MyTestClass) xStream.fromXML(xmlWithNewField);
		assertNotNull(c1);
	}

	@XStreamAlias("myTestClass")
	public class MyTestClass implements Serializable {
		public MyTestClass() {}
	}

Activity

Hide

Permalink

Matthew Lieder added a comment - 03/Jun/13 2:19 PM - edited

The bug appears to be introduced because of the apparent rewrite of AbstractReflectionConverter. In the following new code, CannotResolveClassException is thrown for the "id" field and type is assigned java.net.URL for the "url" field. It would seem that it should throw CannotResolveClassException for "url" too this is the only place that calls the handleUnknownField method.

                        // it is not an alias ... do we have an element of an implicit
                        // collection based on type only?
                        try {
                            type = mapper.realClass(originalNodeName);
                        } catch (CannotResolveClassException e) {
                            handleUnknownField(
                                explicitDeclaringClass, fieldName, resultType, originalNodeName);
                        }

Show

Matthew Lieder added a comment - 03/Jun/13 2:19 PM - edited The bug appears to be introduced because of the apparent rewrite of AbstractReflectionConverter. In the following new code, CannotResolveClassException is thrown for the "id" field and type is assigned java.net.URL for the "url" field. It would seem that it should throw CannotResolveClassException for "url" too this is the only place that calls the handleUnknownField method. // it is not an alias ... do we have an element of an implicit // collection based on type only? try { type = mapper.realClass(originalNodeName); } catch (CannotResolveClassException e) { handleUnknownField( explicitDeclaringClass, fieldName, resultType, originalNodeName); }

Hide

Permalink

Jörg Schaible added a comment - 04/Jun/13 6:57 PM

Thanks for heads up, fixed in trunk.

Show

Jörg Schaible added a comment - 04/Jun/13 6:57 PM Thanks for heads up, fixed in trunk.

Hide

Permalink

Matthew Lieder added a comment - 05/Jun/13 11:09 AM

Thanks so much! Confirmed fixed on our end too.

Show

Matthew Lieder added a comment - 05/Jun/13 11:09 AM Thanks so much! Confirmed fixed on our end too.

People

Assignee:

Jörg Schaible

Reporter:

Matthew Lieder

Votes:

0 Vote for this issue

Watchers:

2 Start watching this issue

Dates

Created:

03/Jun/13 2:16 PM

Updated:

27/Sep/13 2:54 PM

Resolved:

04/Jun/13 6:57 PM