OK, thanks, Daniel, to the point as always! :-) A followup question:
I HAVE looked in the WSDL already (we use SoapUI for testing, hard to avoid seeing the mapping ;-) ) and the data seems to be represented in a very straightforward way as a list of key+value pair structs. Given this, it should be possible to write a XmlJavaTypeAdapter then we should be able to make this protocol backwards compatible on XML/SOAP level? Given what I read and your comment on Aegis it sounds really cool, but it seems it would likely break backward compatibility with older clients that was implemented with JAXB etc then? (since the default type bindings would be different?) On 5 November 2010 17:22, Daniel Kulp <dk...@apache.org> wrote: > > Honestly, I'm surprised this works at all. HashMap is not a type supported > by JAX-WS/JAXB really at all. If you grabthe wsdl (?wsdl on the endpoint), > you would see that for those types, they are empty sequences and thus should > not have any ability to transfer data. > > If you use a very recent version of 2.2.x (like 2.2.11) or 2.3.0 and add: > @DataBinding(AegisDatabinding.class) > to the interfaces, it switches to the Aegisdatabinding which DOES support > HashMaps. When I do that, your tests pass fine. > > The alternative if you need/want to stick to JAXB is that you would need to > write an XmlJavaTypeAdapter thing to convert the maps to/from a List of some > struct to hold the data. See the java-first-jaxws sample in the kit for an > example of this. > > Dan > > > On Thursday 04 November 2010 4:37:12 pm Kent Närling wrote: >> Hi, >> >> Me and my colleagues have written about this problem before, but >> thought we worked around it but now it came back to haunt us... >> >> >> As we already stated, sending HashMap<String, String> in >> requests/responses doesnt seem to work at all, they loose data, become >> corrupted or simply become null, >> As a workaround, we created a wrapper class, using the HashMap, which >> worked MUCH better... until we discovered problems under heavy volume, >> then suddenly this was also corrupted and we even saw signs that the >> response data were mixed up between different requests!! >> >> We were previously asked if this problem was reproducible with a small >> sample... >> (http://cxf.547215.n5.nabble.com/Unmarshalling-a-HashMap-only-works-someti >> mes-td2638328.html) I have now created a small test project that >> re-produces both of these issues in a small code segment. >> There are two unit test classes included : TestUsingHashMap and >> TestUsingHashMapWrapper and each of them has two unit tests, one >> running in a single thread and the other running with 5 threads. >> >> Please, can we get some feedback what is the problem? Any suggested >> workaround? Would it be possible to write our own marshal handlers to work >> around this? >> >> We did some experiments using a plain list of key-value objects which >> seems to work, however this breaks the SOAP compatibility with older >> stuff so this solution is a headache for us. >> >> >> Kent Närling > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
