Hi,
Sorry for not responding promtly as I'm busy with the DataBinding Inteceptor
story. Please see my comments inline below.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 17, 2006 9:45 AM
Subject: Re: svn commit: r432156
On Aug 17, 2006, at 9:29 AM, Raymond Feng wrote:
Hi, Jim.
Sorry for the confusion.
First of all, I want to reassure you that we're still on the same page
for the overrall direction:
Based on your comments below, I'm not sure we are :-)
1. I fully agree with you that it's a real hack and it's only a
temporary fix for one or two weeks while I'm working out the databinding
integration. The hack will be definitely removed before we release the
Axis2 binding.
2. Axis2 binding is an extension instead of part of the core. We need to
deploy it as an extension instead of poluting the webapp runtime.
Here's some background that I decided to add such a hack. Rick had
pinged me to see if we can bring up the Axis2 binding to the same
functionality as it had for M1 so that we can perform the Axis2
intergration tests without having to rewrite all the interop tests using
AXIOM. I thought it's reasonable and a working end-to-end case might
also help me to better understand the core/extension/ databinding
integration picture so that I can get it right quickly. I apologized
that I didn't communicate it clearly before the check-in.
Could you explain why all of the interop tests require SDO? That seems a
bit strange.
We need to exchange some data conforming to the WSDL/XSD. One convenient way
to do that is using a XML databinding framework such as SDO and JAXB. I
happened to pick SDO just because I'm familar with SDO and I wanted to stay
with SDO as the starting point as the M1 does.
I don't think this should be checked into the main line but rather done
in the sandbox as it violates one of the architecture principles we set
forth. In terms of working out databinding integration, this should
really be done through unit testing as much as possible first. Note that
none of the steps you mentioned below need to be done outside the context
of core, much less require breaking modularity.
I promise I'll be more cautious next time.
Anyway, here's the path I'm full-time on now to work toward the solution
that we have been discussing on this list.
1. Integrate the DataBinding framework with the ServiceContract/
Operation/DataType model
2. Integrate the DataBinding framework with the wiring fabric using an
Interceptor
* Associate some databinding-related context to the composite
hierachary
* Adjust the builder delegation strategy
* Attach an interceptor the wiring fabric to perform the data
transformation based on the databinding context
* Question: Do we model databinding as a policy or part of the
core?
Data binding should be done as part of the wiring infrastructure in core.
"Policy" is a euphemism for the the part of core that introduces
interceptors and handlers, and is itself extensible. We may need to
modify it somewhat so that the databinding policy builder has information
about the target and source of a wire.
Thank you for the information. I'm actively looking into the policy builder
now to get the databinding into the wiring infrastructure as interceptors.
I'll post the progress and questions as I go.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 17, 2006 12:14 AM
Subject: Fwd: svn commit: r432156
Raymond,
I've noticed an SDO and databinding implementation dependencies have
been introduced into the Axis2 binding. Based on your comments in the
code, it appears this is temporary and related to implementing an
interceptor into the policy framework. I'd prefer that we work on
getting the correct solution in place ASAP and am uncomfortable with
introducing hacks such as this one. There was an email thread the
other day about introducing an interceptor and am happy to provide
assistance if required.
Could you please outline what is required so we can work towards a
proper solution?
Thanks,
Jim
Modified:
incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/Axis2Reference.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/Axis2Service.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/
Axis2ServiceInOutSyncMessageReceiver.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/Axis2TargetInvoker.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/util/SDODataBinding.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/ java/
org/apache/tuscany/binding/axis2/util/ TuscanyAxisConfigurator.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/main/
resources/META-INF/sca/default.scdl
incubator/tuscany/java/sca/bindings/binding.axis2/src/test/ java/
org/apache/tuscany/binding/axis2/Axis2ReferenceTestCase.java
incubator/tuscany/java/sca/bindings/binding.axis2/src/test/ java/
org/apache/tuscany/binding/axis2/Axis2ServiceTestCase.java
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
