Hi,
Please see my updates below.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, September 04, 2006 8:35 PM
Subject: Databinding transformation
Hi Raymond,
I have (finally) added support for the data binding framework to be
plugged into the wiring infrastructure. To do this, you can follow these
steps:
1. Extend JavaInterfaceProcessorExtension with an implementation that
understands service contract annotations and updates ServiceContract or
Operation. Right now, each implementation processor must introspect the
class associated with the ServiceContract as opposed to using a more
granular visitor as was done for the implementation processors. I think
this is the right way to go about it but if we find a more granular
approach is easier, it will be a trivial change. I also added metadata
maps on ServiceContract and Operation for additional data binding (or
other) information.
Yes, I got the DataBindingJavaInterfaceProcessor plugged in. I guess I also
need to add a DataBinding StAX loader to deal with the metadata provided in
the SCDL extensions which should override the java annotations.
Question 1: Do we allow different databinding decorations against the same
interface for different references/services? If so, we will have to keep
different instances of ServiceContract(s) even they are introspected from
the same interface.
Question 2: Do we support operation overloading? If yes, we cannot use the
operation name as the key in the ServiceContract.
2. Extend WirePostProcessorExtension with an implementation that will
introspect the ServiceContract on a wire and operation, updating
invocation chains based on metadata. Wire post processors are called by
the connector after all policies have been added and the target wire
resolved but before the source and target wires are connected. These post
processors must be careful not to "over-optimize" target chains as
multiple source wires may be attached to them (e.g. when two components
wire to the same reference). In the databinding case, the transformation
interceptor must be placed on the source side. As policy comes in, I'm
sure we are going to have interesting scenarios to resolve (e.g. where do
we add the intereceptor, what about handlers, etc.).
Yes, I got DataBindingWirePostProcessor plugged in after I fixed the
"@Init(eager = true)" problem in WirePostProcessorExtension.
Another two issues:
1. We have inconsistent usages of parameterized Operation in InboundWire and
OutboundWire. I fixed it locally and will check the changes in if we agree.
2. I ran into an IllegalArgumentException when I try to add the
DataBindingInterceptor to the invocation chain by calling addInterceptor
because the TargetInvokerInterceptor has been added by JDKWireService and it
has to be the last interceptor. We discussed this issue before on the
mailing list.
A related question:
How do we calculate the equality of two operations for the source wire and
the target wire? We use Operation as keys for the invocation chains. By the
SCA spec, the two ServiceContracts are only required to be compatible, so
are the Operations. The following is quoted from the spec:
"A wire may only connect a source to a target if the target implements an
interface that is compatible with the interface required by the source. The
source and the target are compatible if:
1. the source interface and the target interface MUST either both be
remotable or they are both local
2. the methods on the target interface MUST be the same as or be a superset
of the methods in the interface specified on the source
3. compatibility for the individual method is defined as compatibility of
the signature, that is method name, input types, and output types MUST BE
the same.
4. the order of the input and output types also MUST BE the same.
5. the set of Faults and Exceptions expected by the source MUST BE the same
or be a superset of those specified by the service.
6. other specified attributes of the two interfaces MUST match, including
Scope and Callback interface
A Wire can connect between different interface languages (eg. Java
interfaces and WSDL portTypes) in either direction, as long as the
operations defined by the two interface types are equivalent. They are
equivalent if the operation(s), parameter(s), return value(s) and
faults/exceptions map to each other."
Let me know how this goes.
Jim
BTW, I'm going to start to add in support for XStream (http://
xstream.codehaus.org/) since it will give us a POJO-based data binding
framework, support for complex Java types, and alternative serializations
(including JSON) so I may be asking you questions about the databinding
API soon.
---------------------------------------------------------------------
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]
