[
http://jira.codehaus.org/browse/XFIRE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92880
]
bill graham commented on XFIRE-842:
-----------------------------------
After many struggles I've also been able to get Maps working with
Java5/Generics. The workaround in the above example is to name your services
namespace with the default namespace of the beans (or vice-versa, but I
couldn't get that working). To follow the example above we have this:
service namespace -> services.c.b.a.com
bean namespace -> presentation.c.b.a.com
which is what causes the conflict when reading a map. I'm trying to read from
the client and this happens regardless of what the namespaces are on my wsdl on
the server. The default service namespace is the inverted package structure of
the service interface. Similarly the default for the beans is the inverted
package name of the bean location. The two need to match for maps to be
handled. I'm not sure if this is a bug with MapType or not, but this behavior
doesn't surface itself for Collections so it seems like MapType has
inconsistent behavior.
The workaround (using annotations) was to add this to the service interface
used by my client:
@WebService(
serviceName = "SomeService ",
endpointInterface = "com.a.b.c.services.SomeService ",
targetNamespace = "presentation.c.b.a.com"
)
public interface SomeService {
public SomeObjectWithAMap getSomeObject(RequestObject request);
}
Dan, in lieu of a code sample I think this should help to reproduce the issue.
By changing the targetNamespace above you should see the problem.
> 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
> Assignee: Dan Diephouse
> Priority: Blocker
> Fix For: 1.2.6
>
>
> 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
