On Sunday 07 November 2010 3:37:42 pm Kent Närling wrote:
> 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.
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.
> 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.
> 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.
Dan
>
> On 5 November 2010 17:22, Daniel Kulp <[email protected]> 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
> > [email protected]
> > http://dankulp.com/blog
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
