For binding.jms wireFormat.jmsdefault, consider smoothing over
elementFormDefault differences
---------------------------------------------------------------------------------------------
Key: TUSCANY-2992
URL: https://issues.apache.org/jira/browse/TUSCANY-2992
Project: Tuscany
Issue Type: Improvement
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
Priority: Minor
So another area where this wF.jmsdefault behavior of unwrapping a single
input/output gets tricky is with respect to elementFormDefault, and let me
bring up another area to consider.
Consider the wrapped case, either top-down <interface.wsdl> or bottom-up
<interface.java> - (the default in the absence of JAX-WS annotations being to
treat Java as wrapped.)
While, (according to the JMS binding spec's description of the default WF), we
have to read or write the wrapper's single child, the schema-defined element in
play is actually the operation-level wrapper element. The wrapper element's
schema's elementFormDefault, then, will intersect with whether our child
element is NS-qualified or not.
When serializing (request or response), the thing to do seems simple enough:
use the elementFormDefault of the wrapper elem definition to decide whether to
serialize the child element with a NS ("qualified") or without a NS
("unqualified", the default).
So for:
<wsdl:types>
<schema elementFormDefault="qualified" xmlns:tns="http://test";
targetNamespace="http://test"; ...>
<element name="myOperation">
<complexType>
<sequence>
<element name="arg1" type="xsd:int"/>
</sequence>
</complexType>
</element>
we serialize:
<tns:arg1>4</tns:arg1>
whereas if we change the schema to elementFormDefault="unqualified" (note this
is the default for bottom-up generated schemas as well)
we serialize:
<arg1>4</arg1>
Seems simple enough, but what about deserialization?
One approach would be to require the "other side" to understand the viewpoint
of the SCA runtime doing the deserialization and whether or not the SCA runtime
expects qualified or unqualified child elements (this is how our code is
implemented today).
According to this approach, receiving a JMS payload like:
<tns:arg1>4</tns:arg1>
together with a service described by interface.java method such as:
void myOperation(int x);
would be a user error. The Java, absent JAXB annotations, maps to a schema
with elementFormDefault="unqualified", and so we can't handle such a payload.
An alternative approach would be to implement deserialization such that it
could smooth over differences in elementFormDefault, i.e. handle either the
unexpected presence or absence of a NS by ignoring or adding the NS as
necessary. (Even then we could ask: should a NS that's present but incorrect
also be smoothed over (ignored)?)
Do we agree this change would be desirable?
I wish I had more sense of how useful in practice this change would be. Not
knowing that, at least opening the issue reminds us the issue exists, for later
when someone asks why their data is null (as this is what happens in JAXB when
you get the elemFormDefault incorrect).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
