Hi,
It seems that we have to revisit this issue again. During past discussions, we
thought it would be sufficient to only support interface and operation level
databinding declarations and assumed that mixed databindings on the same
operation was crazy :-).
I now have difficulties to identify which parameters for a java method should
be transformed based on the interface/operation level databinding. Let's have
an example below.
Case 1: The "xml" parameter is an XML string, but "plainStr" is a simple plain
string
@DataType(name="xml:string")
String myOp(String xml, String plainStr, int i);
I can ssume that parameters with primitive types such as "i" bear
JavaDataBinding but I cannot differentiate "xml" and "plainStr" (neither the
return value).
Case 2:
@DataType(name="commonj.sdo.DataObject)
Address getCustomer(Customer customer, String str, Object obj);
Is it reasonable to have "Customer" a DataObject and "Address" a java bean? How
about "obj"?
The key issue here is that java method by default uses JavaDataBinding.
Declaring a different databinding such as XMLString or SDO actually starts to
have mixed databindings for one method.
Interestingly, this issue is not really a problem for WSDL which usually types
the operation parameters as XSD types and a java/xml binding technology such as
AXIOM, DOM, SDO or JAXB comes behind it. One databinding for the whole WSDL
port type sounds reasonable.
I have a proposal to add an attribute to the operation level databinding
declarations to explicitly spell out the list of parameters (or return value).
@DataType(name="commonj.sdo.DataObject" parameters={0, 2, -1}) // "parameters"
is a list of indexes for the args, -1 for return value
If "parameters" is not specified then we assume it applies to all parameters
and the return value.
What do you guys think?
Thanks,
Raymond
