On Sep 27, 2006, at 9:32 AM, Raymond Feng wrote:
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"?
This seems a bit strange. What meaning do str and obj have in the
service contract? Maybe there is a better example?
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
Indexing like this is error prone and difficult to read. If do need
multiple parameter types, we should have an an optional attribute
specifying the return type and a collection of data types for
parameters similar to @Constructor
If "parameters" is not specified then we assume it applies to all
parameters and the return value.
What do you guys think?
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
