Re: [castor-dev] [XML] UnmarshalHandler behavior with invalid Map collections
Keith-
Bugs are posted (1830, 1831). Thanks for the help.
Stephen
Keith Visco wrote:
Hi Stephen,
Both Funny Things appear to be legitimate bugs. The first being a bug
in the error reporting and the second being a bug in the traversing of
the state stack. Your solution should work, but instead of checking for
a null fieldDesc it should probably check to see if the state is a place
holder for a wrapper element and if so, keep looking up the stack.
It would be great if you could open up bug reports on these in our
Bugzilla (http://bugzilla.exolab.org).
Thanks,
--Keith
Stephen Bash wrote:
Hello all. I'm a newbie to the list, so while I will do my best to
follow the guidelines, constructive criticism is welcome. I recently
began using Castor (v0.9.5.4-xml) to do XML data binding on an
existing Java object model. The Java model includes several Maps, and
it is there that I've discovered some odd behavior. The two cases are
outlined below, with code and xml examples at the end of the message.
Any comments on my implementations are welcome, but I'd also like to
know what the developers think of these issues (I don't want to run
into a feature and think it is a bug...) Thank you for your time.
Funny Thing 1:
This behavior was actually discovered when debugging behavior 2 below,
but it is easier to describe first. I begin with an object that
contains a Map (in my case, a java.util.HashMap), which is correctly
marshaled using a mapping file and identifying the field using
collection=map. The XML file is then changed by some outside
influence such that one of the key elements has two value elements
following it (making the XML an invalid representation of the Java
object). When the XML file is then unmarshaled by Castor, it
correctly reports the error ('element value occurs more than once'),
but when it gives the path to the element, it lists
/mapName/mapName/value rather than /rootElement/mapName/value. In a
brief survey of the code, I think this is tied to line 938 in the
UnmarshalHandler (location = state.elementName + / + location;)
which should read tmpState.elementName instead of state.elementName.
Java code, exception message, and XML files are included below.
Funny Thing 2:
In the same situation as above, unmarshaling an invalid XML
representation of a Map, a NullPointerException will be raised on line
937 of the UnmarshalHandler if the map is enclosed in an element using
the location attribute in the bind-xml element of the mapping file.
The null pointer arises when the UnmarshalHandler attempts to get a
field descriptor on the enclosing element. My guess is a simple null
check should eliminate the problem (i.e. if tmpState.fieldDesc is
null, just add the XML element name to location and continue up the
tree looking for an element that does have a field descriptor).
Again, Java code, exception message, and XML files are below.
Examples for Behavior 1: (Some items stripped for length)
Java Code:
Mapping barMap1 = new Mapping();
barMap1.loadMapping( barMap1.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap1 );
Bar test = (Bar)um1.unmarshal(new FileReader(UnmarshalEx1.xml));
Exception Stack Trace:
element value occurs more than once. (parent class:
org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
ValidationException: element value occurs more than once. (parent
class: org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:943)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1076)
at
org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1180)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1201)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:952)
at
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
at
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
at UnmarshalEx1.main(UnmarshalEx1.java:41)
Mapping file:
mapping
class name=foo.Bar
map-to xml=FooBar /
field name=data collection=map
bind-xml name=FooBarData /
/field
/class
/mapping
Data File:
FooBar
FooBarData
keyTestKey/key
valueTestValue/value
valueTestValue/value
/FooBarData
/FooBar
Examples for Behavior 2: (Some items stripped for length)
Java Code:
Mapping barMap2 = new Mapping();
barMap2.loadMapping( barMap2.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap2 );
Bar test =
[castor-dev] [XML] UnmarshalHandler behavior with invalid Map collections
Hello all. I'm a newbie to the list, so while I will do my best to
follow the guidelines, constructive criticism is welcome. I recently
began using Castor (v0.9.5.4-xml) to do XML data binding on an existing
Java object model. The Java model includes several Maps, and it is
there that I've discovered some odd behavior. The two cases are
outlined below, with code and xml examples at the end of the message.
Any comments on my implementations are welcome, but I'd also like to
know what the developers think of these issues (I don't want to run into
a feature and think it is a bug...) Thank you for your time.
Funny Thing 1:
This behavior was actually discovered when debugging behavior 2 below,
but it is easier to describe first. I begin with an object that contains
a Map (in my case, a java.util.HashMap), which is correctly marshaled
using a mapping file and identifying the field using collection=map.
The XML file is then changed by some outside influence such that one of
the key elements has two value elements following it (making the XML
an invalid representation of the Java object). When the XML file is
then unmarshaled by Castor, it correctly reports the error ('element
value occurs more than once'), but when it gives the path to the
element, it lists /mapName/mapName/value rather than
/rootElement/mapName/value. In a brief survey of the code, I think this
is tied to line 938 in the UnmarshalHandler (location =
state.elementName + / + location;) which should read
tmpState.elementName instead of state.elementName. Java code, exception
message, and XML files are included below.
Funny Thing 2:
In the same situation as above, unmarshaling an invalid XML
representation of a Map, a NullPointerException will be raised on line
937 of the UnmarshalHandler if the map is enclosed in an element using
the location attribute in the bind-xml element of the mapping file.
The null pointer arises when the UnmarshalHandler attempts to get a
field descriptor on the enclosing element. My guess is a simple null
check should eliminate the problem (i.e. if tmpState.fieldDesc is null,
just add the XML element name to location and continue up the tree
looking for an element that does have a field descriptor). Again, Java
code, exception message, and XML files are below.
Examples for Behavior 1: (Some items stripped for length)
Java Code:
Mapping barMap1 = new Mapping();
barMap1.loadMapping( barMap1.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap1 );
Bar test = (Bar)um1.unmarshal(new FileReader(UnmarshalEx1.xml));
Exception Stack Trace:
element value occurs more than once. (parent class:
org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
ValidationException: element value occurs more than once. (parent
class: org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:943)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1076)
at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1180)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1201)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:952)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
at UnmarshalEx1.main(UnmarshalEx1.java:41)
Mapping file:
mapping
class name=foo.Bar
map-to xml=FooBar /
field name=data collection=map
bind-xml name=FooBarData /
/field
/class
/mapping
Data File:
FooBar
FooBarData
keyTestKey/key
valueTestValue/value
valueTestValue/value
/FooBarData
/FooBar
Examples for Behavior 2: (Some items stripped for length)
Java Code:
Mapping barMap2 = new Mapping();
barMap2.loadMapping( barMap2.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap2 );
Bar test = (Bar)um1.unmarshal(new FileReader(UnmarshalEx2.xml));
Exception Stack Trace:
java.lang.NullPointerException
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:937)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1076)
at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1180)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1201)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at
Re: [castor-dev] [XML] UnmarshalHandler behavior with invalid Map collections
Hi Stephen,
Both Funny Things appear to be legitimate bugs. The first being a bug
in the error reporting and the second being a bug in the traversing of
the state stack. Your solution should work, but instead of checking for
a null fieldDesc it should probably check to see if the state is a place
holder for a wrapper element and if so, keep looking up the stack.
It would be great if you could open up bug reports on these in our
Bugzilla (http://bugzilla.exolab.org).
Thanks,
--Keith
Stephen Bash wrote:
Hello all. I'm a newbie to the list, so while I will do my best to
follow the guidelines, constructive criticism is welcome. I recently
began using Castor (v0.9.5.4-xml) to do XML data binding on an existing
Java object model. The Java model includes several Maps, and it is
there that I've discovered some odd behavior. The two cases are
outlined below, with code and xml examples at the end of the message.
Any comments on my implementations are welcome, but I'd also like to
know what the developers think of these issues (I don't want to run into
a feature and think it is a bug...) Thank you for your time.
Funny Thing 1:
This behavior was actually discovered when debugging behavior 2 below,
but it is easier to describe first. I begin with an object that contains
a Map (in my case, a java.util.HashMap), which is correctly marshaled
using a mapping file and identifying the field using collection=map.
The XML file is then changed by some outside influence such that one of
the key elements has two value elements following it (making the XML
an invalid representation of the Java object). When the XML file is
then unmarshaled by Castor, it correctly reports the error ('element
value occurs more than once'), but when it gives the path to the
element, it lists /mapName/mapName/value rather than
/rootElement/mapName/value. In a brief survey of the code, I think this
is tied to line 938 in the UnmarshalHandler (location =
state.elementName + / + location;) which should read
tmpState.elementName instead of state.elementName. Java code, exception
message, and XML files are included below.
Funny Thing 2:
In the same situation as above, unmarshaling an invalid XML
representation of a Map, a NullPointerException will be raised on line
937 of the UnmarshalHandler if the map is enclosed in an element using
the location attribute in the bind-xml element of the mapping file.
The null pointer arises when the UnmarshalHandler attempts to get a
field descriptor on the enclosing element. My guess is a simple null
check should eliminate the problem (i.e. if tmpState.fieldDesc is null,
just add the XML element name to location and continue up the tree
looking for an element that does have a field descriptor). Again, Java
code, exception message, and XML files are below.
Examples for Behavior 1: (Some items stripped for length)
Java Code:
Mapping barMap1 = new Mapping();
barMap1.loadMapping( barMap1.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap1 );
Bar test = (Bar)um1.unmarshal(new FileReader(UnmarshalEx1.xml));
Exception Stack Trace:
element value occurs more than once. (parent class:
org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
ValidationException: element value occurs more than once. (parent
class: org.exolab.castor.mapping.MapItem)
location: /FooBarData/FooBarData/value
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:943)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1076)
at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1180)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1201)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:952)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
at UnmarshalEx1.main(UnmarshalEx1.java:41)
Mapping file:
mapping
class name=foo.Bar
map-to xml=FooBar /
field name=data collection=map
bind-xml name=FooBarData /
/field
/class
/mapping
Data File:
FooBar
FooBarData
keyTestKey/key
valueTestValue/value
valueTestValue/value
/FooBarData
/FooBar
Examples for Behavior 2: (Some items stripped for length)
Java Code:
Mapping barMap2 = new Mapping();
barMap2.loadMapping( barMap2.xml );
Unmarshaller um1 = new Unmarshaller();
um1.setMapping( barMap2 );
Bar test = (Bar)um1.unmarshal(new FileReader(UnmarshalEx2.xml));
Exception Stack Trace:
