On Thu, Mar 26, 2009 at 4:07 PM, Scott Kurz wrote:
> Simon,
>
> Still looking over your changes just wanted to respond that my
> impression & working understanding has been that we assume we have
> unique operation names in a bunch of places and use String.equals()
> for operation name matchin
[1.x] API change for TUSCANY-2931?
Simon,
Still looking over your changes just wanted to respond that my
impression & working understanding has been that we assume we have
unique operation names in a bunch of places and use String.equals()
for operation name matching... certainly withi
Simon,
Still looking over your changes just wanted to respond that my
impression & working understanding has been that we assume we have
unique operation names in a bunch of places and use String.equals()
for operation name matching... certainly within some binding
implementations... so making
Ok, thanks Scott/Raymonds, I've checked the changes in so we can all
take a look at them (revision: 758625 ). One particular issues that
has come up is to do with how interface operations are located in
order to be updated in the case where request and response wire
formats are not the same.
I've
+1. The proposed changes are good and they are fairly isolated.
Thanks,
Raymond
--
From: "Simon Laws"
Sent: Wednesday, March 25, 2009 7:06 AM
To: "tuscany-dev"
Subject: [1.x] API change for TUSCANY-2931?
I
On Wed, Mar 25, 2009 at 3:46 PM, Scott Kurz wrote:
> Simon, that all sounds good to me.
>
> It was only recently that I'd even run across the need to maybe look
> at isWrapperStyle(), from say, a binding impl, in the case of
> implementing the wireFormat.jmsdefault behavior of sending a single
> a
Simon, that all sounds good to me.
It was only recently that I'd even run across the need to maybe look
at isWrapperStyle(), from say, a binding impl, in the case of
implementing the wireFormat.jmsdefault behavior of sending a single
argument unwrapped. The new API should work well with that use
I have a fix for http://issues.apache.org/jira/browse/TUSCANY-2931 but
it implies an API change. In particular to support the separation of
input from output wrappers :
org.apache.tuscany.sca.interfacedef.Operation
getWrapper() -> getInputWrapper() & getOutputWrapper()
setWrapper() -> se
