Hi again Daniel, thanks for the feedback! > > When I run your test case for the non-wrapped case and look at the wsdl, I > just see: > > > <xs:complexType name="hashMap"> > <xs:complexContent> > <xs:extension base="tns:abstractMap"> > <xs:sequence /> > </xs:extension> > </xs:complexContent> > </xs:complexType> > <xs:complexType abstract="true" name="abstractMap"> > <xs:sequence /> > </xs:complexType> > > Which doesn't show any type of key/value thing. I do see the key/value thing > with the wrapper case though. Kind of interesting that there is a difference. Yes, isn't it interesting? ;-) ... but then it doesnt matter anymore, it is an odd side effect we cannot rely on anyway as we found out...
> >> 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? > > In theory, yes. You COULD actually run wsdl2java on the wsdl and just use > the beans it creates for the map entries in your type adapter. Might be the > easiest starting point. We already did this manually, seems to work nicely, thanks for the tip! :-) > > >> 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?) > > Probably yes depending on the complexity of the data objects. I tested this and confirmed that backwards compatibility becomes messy, also even though Aegis seems very nice we need to prioritize compatibility with third-party clients and then going with JAXB seems the safest. > > Dan > > > >> >> 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-some >> >> ti 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 > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
