On Thu, Feb 14, 2013 at 03:52:46PM +0000, Sergey Beryozkin wrote:
> On 14/02/13 15:45, Sergey Beryozkin wrote:
> > Hi
> > On 14/02/13 14:55, James Talbut wrote:
> >> Hi,
> >>
> >> I have a base class ("ExtensionArgumentType") which has ~12 different
> >> sub classes derived from it.
> >> The classes themselves are all defined in an XSD and are primarily
> >> used in SOAP.
> >>
> >> When I try to communicate with the server using WebClient I get
> >> something like:
> >>
> >> "ExtensionArgument" : [{
> >> "@xsi.type" : "ns2:ParameterValueType",
> >> "ns2.Name" : "ScalarParameter",
> >> "ns2.Value" : "Value1"
> >> }, {
> >> "@xsi.type" : "ns2:ParameterValueType",
> >> "ns2.Name" : "ScalarComboParameter",
> >> "ns2.Value" : "Value2"
> >> }
> >>
> >> I don't mind having the "@xsi.type" parameter there, and I'm happy to
> >> write whatever would be useful in it, but:
> >> 1. There is no ns1 anywhere in the HTTP request from WebClient, so how
> >> do I know which prefix to use?
> >> 2. I don't want to have prefixes on the other elements (Name& Value).
> >>
> >> If I tell the client to ignore namespaces it won't write the xsi.type
> >> at all.
> >> If I introduce a namespace map and give it an entry from my namespace
> >> to nothing it removes the namespace from Name/Value, but leaves ns2 on
> >> the type name.
> >> If I introduce a namespace map and give it an entry from my namespaec
> >> to something that prefix is used for Name, Value& type.
> >>
> >> Is there any way to get what I'm after?
> >>
> > Passing this with JSON is tricky, and the immediate workaround I can
> > think of is to get the receiving end to map "ns2" to a specific
> > namespace (with namespace map), but in your case I guess there could be
> > up to 12 namespaces...
> >
> >
> > I can think of a workaround where JSONProvider which sends the data is
> > configured (via transformation properties) to structure the payload such
> > that it has enough hints for the receiving JSONProvider to convert the
> > incoming payload (also with transformation properties) for JAXB to map
> > it correctly
> >
> > I wonder if should enhance StaxTransformFeature to change prefixes when
> > needed too...so for every specific subtype you'd be able to use a
> > dedicated prefix and thus manage the namespace map on the receiving end
> > better...
> >
> Actually, that won't help, as you said:
> >>If I introduce a namespace map and give it an entry from my namespaec
> >>to something that prefix is used for Name, Value& type.
>
> well, custom hints is the only thing I can think of at the moment...but
> the fact that xsi prefix is lost will need to be fixed at Jettison level
>
>
> > Cheers, Sergey
>
Thanks for the response(s) Sergey,
I guess what I think would be the simple response is to separate the namespace
used in xsi:type from that used for the elements.
I'd be quite happy with:
"ExtensionArgument" : [{
"@xsi.type" : "custom:ParameterValueType",
"Name" : "ScalarParameter",
"Value" : "Value1"
}, {
"@xsi.type" : "custom:ParameterValueType",
"Name" : "ScalarComboParameter",
"Value" : "Value2"
}
If setWriteXsiType were independent of setIgnoreNamespaces could this work?
At the moment, the checks in JSONProvider combine those two flags together so I
can't have writeXsiType = true with ignoreNamespaces = false.
If I could have that combination, with a namespace map, it looks (from a point
of view of total ignorance) like I'd get what I'd want.
Yes, I'd need namespace map entries for each namespace I reference, but I can
live with that as long as they are only referenced in the xsi:type elements.
The other option would be to make the namespace map to "" work for the xsi:type
like it does for the elements, but I wouldn't be surprised to find that that
was
unacceptable to the JSON reader (in my case there are no local name clashes,
but you'd have to think what to do when clashes did occur).
The reason for wanting this is that the client is a jQuery web app.
No matter what I do the xsi:type values are going to be hardcoded to something,
so it's no hardship to store them with the right prefixes.
But the other elements need to be manipulated in javascript and having the
prefixes on them would be a serious pain.
Jim
