[ http://jira.codehaus.org/browse/XFIRE-842?page=comments#action_85176 ] Andrzej Doyle commented on XFIRE-842: -------------------------------------
This may actually be caused by using a legacy version of Woodstox (2.0.6). I note that versions earlier than 3.0.3 are deemed as legacy and that XFire's dependancy guide has been updated accordingly. I'll ensure all my libraries are up to date and see if this issue persists. > 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
