On Sep 5, 2006, at 11:13 AM, Raymond Feng wrote:
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.
Yea sorry I forgot that.
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.
Yea I think I forgot to go back and parameterize. Can you check that
in later as part of the work you are doing?
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.
Yea this doesn't seem right. It should probably be moved after the
post processors. Can you check your changes in and I'll take a look
since I think some other areas may be affected?
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
The Operation.equals() method may need to be slightly updated but it
implements most of this.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
