Hi Raymond,
This is something that I picked up from ASM. This is the way method
signatures are input to the ASM Bytecode Generator. Anyways, here is an
attempt. I have modified the opertation bindings to bring out what was in
my mind. I have used square-brackets ([) for some clarity only... so that
you are able to quickly delimit paramters and return result.
@Remotable
@DataBinding(name = "sdo") // Interface-level databinding declaration
public interface Dummy {
// Order and Shipment are SDO DataObject(s), Date is a plain java object
Shipment createShipment(Order order, Date deadline);
@DataBinding
[(name="jaxb", attributes={ @DataAttr(name ="contextPath", value= "
com.example.ipo.jaxb") }),(name="java")](name="jaxb", attributes={
@DataAttr(name ="contextPath", value= "com.example.ipo.jaxb")})
}
In this, we explicitly mention the target types for all parameters and also
the return type. The databinding framework would transform only if the
source and target types are different. So in the case of the second
parameter 'deadline' there would be no conversion since the framework will
find that the source and target type are both Java.
Thanks
- Venkat
On 9/28/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Inspired by the JAX-WS/JSR 181 annotation styles, I come out with the
following example.
@Remotable
@DataBinding(name = "sdo") // Interface-level databinding declaration
public interface Dummy {
// Order and Shipment are SDO DataObject(s), Date is a plain java
object
// @DataParam marks the parameter and @DataResult marks the return
value, please note @DataResult applies to "METHOD". Both are optional
@DataResult Shipment createShipment(@DataParam Order order, Date
deadline);
@DataBinding(name = "jaxb", attributes = { @DataAttr(name =
"contextPath", value = "com.example.ipo.jaxb") }) // operation-level
databinding
@DataResult CreditReport checkCredit(@DataParam Customer customer);
@DataBinding(name = "xml:string")
@DataResult String evaluate(@DataParam String xml, String xpath);
}
Venkat, can you illustrate your syntax with my example so that I
understand
better?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 27, 2006 11:09 PM
Subject: Re: Parameter-level databinding support
>
> On Sep 27, 2006, at 11:04 PM, Venkata Krishnan wrote:
>
>> Hi Raymond,
>>
>> I agree with Jim on that the indexing is cryptic. How about this...
>>
>> @DataType((<arg1_type>, <arg2_type>)<returnType>).
>>
> This to me is a lot easier to follow. Raymond, to the higher level
> question, the example seems a bit strange so maybe you can explain it
> further?
>
> Jim
>
>> i.e. we specify for all arguments and the returntype. The transformer
>> decides to transform only those whose source and target types differ.
>> Makes
>> sense ?
>>
>> Thanks
>>
>> - Venkat
>>
>>
>> On 9/27/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> 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]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
