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?
I've just confirmed that if one explicitly configures namespace map like
this:
Map<String, String> namespaceMap = new HashMap<String, String>();
namespaceMap.put("http://www.w3.org/2001/XMLSchema-instance";, "xsins");
then it bypasses the xsi attribute check and works even if the
namespaces are ignored, so simply assign any prefix but the default
"xsi" to "http://www.w3.org/2001/XMLSchema-instance"; and it should do :-)
HTH, Sergey
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
