Map entries not reconstructed on other side of WS call due to namespace mismatch
--------------------------------------------------------------------------------
Key: XFIRE-842
URL: http://jira.codehaus.org/browse/XFIRE-842
Project: XFire
Issue Type: Bug
Components: Aegis Module
Affects Versions: 1.2.4
Environment: Discovered on server running Jetty 5.1.10, though this
appears to occur universally
Reporter: Andrzej Doyle
Assigned To: Dan Diephouse
Priority: Blocker
I have a simple Map<String, String> as one of the bean properties of an object
that is being sent across the wire. When this object is being written out on
the client side, the EntryWriter used has a namespace of "services.c.b.a.com"
(anonymised). This is more or less what I would expect from the generation; at
least, it matches the QName for my map entries according to the map's Type (as
it should from line 180).
When the parameter is read on the server side, flow correctly passes into
MapType.readObject(). The object that this method is called on is identical to
the serialising object on the server; specifically, it also has an entry type
QName of "services.c.b.a.com". However, when the call goes out to
reader.getNextElementReader() (line 61), the ElementReader that is returned
inherits its name from the 'root' reader - and this is set to
"presentation.c.b.a.com". As a result, the test on line 63 fails as the
namespaces are different, and no map entries are ever read.
As a result my maps are always recreated empty on the other side of the WS call.
This seems to be an issue within the MapType - if the ElementReader on the
write side is created to have the same namespace as the map's type, then surely
this should be the same on the read side. Currently it seems that this will
fail any time MapType.getKeyName() != ElementReader.root.getName().
I haven't attached any test cases as I'm not familiar with how the
MessageReaders passed into MapType.readObject() are created, and when & why the
above inequality occurs. I'll step through the debugger and try to come up
with some tests, but I'm submitting the bug now in the hope that someone with
more familiarity in that area will be able to quickly see what the root cause
is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
