Map entries not reconstructed on other side of WS call due to namespace mismatch

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.

This problem still persists with the latest value of Woodstox. I've had a brief look through the code and it seems that the 'root' reader is created in XFireServletController.invoke() (line 294), but I can't work out at what stage its name is determined.

Thanks. That information should help us track down the problem. Any chance you can create a sample which recreates this problem?

I'm working on creating a sample, but in the process of doing so I think my analysis was incorrect. I initially assumed that 'root' referred to something like the document element, but now I get the feeling it means something more like 'lowest-level'; in any event, modifying the MapTypeTest JUnit test case suggests that the blame doesn't lie where I originally thought.

I've had more of a look at the writing side as a result and it seems there's a major discrepancy there... despite the MessageWriters that create the map, entry and key element having the "

(Oops, there's apparently a submit short cut I hit by mistake. Continuing

...having "services.c.b.a.com" as their namespace, according to java interrogation, the actual XML document produced has "presentation.c.b.a.com" as the output, which would explain why there's a mismatch. With this new information, it seems that the reading side is doing completely the right thing - and while the write side tries to do the right thing, it's not happening somehow.

FYI, the actual root writer in this situation is an instance of org.codehaus.xfire.util.stax.W3CDOMStreamWriter.

I'll continue the investigation and see if I can produce some failing test cases.

A failing test case would be awesome. I can probably get out a fix very easily if you have one.

According to the description, this problem always exists for Maps.
I can confirm this is not the case. I use an object containing 2 Hashtable Maps which are correctly serialized/deserialized by XFire.
The one difference I see in our case compared to this example, is that we have our own Aegis binding files which define a custom namespace for the objects. Also, in the binding file I specify the map attribute as class java.util.Hashtable.
We cannot only successfully transfer Map<String,String>, but also Map<String,Object> and Map<String,List<ValueObject>>

Hope this helps in finding the real problem.

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.

Is any work being done on this issue?
We have just created a web services application that passes maps around and are having big problems with this.