[
http://jira.codehaus.org/browse/XFIRE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85591
]
Dan Diephouse commented on XFIRE-842:
-------------------------------------
A failing test case would be awesome. I can probably get out a fix very easily
if you have one.
> 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
> Fix For: 1.2.5
>
>
> 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
