Since this thread has died down, I decided to checkin the incremental
change I made inspired by this discussion, into 2.x in r1070926 (and
1070928). I mentioned this in my comment on TUSCANY-3832, which was
an issue I found in trying to make this fix.
In terms of comprehensibility, my patch
On Fri, Jan 28, 2011 at 5:38 PM, Raymond Feng enjoyj...@gmail.com wrote:
First, I agree that we could use a better name for the first flag, for
example:
unwrapped or subjectToWrapping
true: the parameters are child elements of the wrapper (doc-lit-wrapper or
RPC wrapper)
false: the parameter
Hi,
Sorry for not replying promptly.
I agree the terms are pretty confusing. We can probably simplify them as
follows:
1) We need to have two flags for a given operation that has corresponding WSDL:
a) dataWrapped: If the payload for the method signature is either already
wrapped
b)
Raymond,
Thanks for writing that up in such detail to move the discussion forward.
Before I respond.. I got a bit lost when you said:
2 When we introspect the Java interface (maybe with JAX-WS annotations), we
can set the flag
a) is set true only if the @SOAPBinding.parameterStyle ==
Raymond,
Ah..thanks for the clarification...I think I see what you're saying.
I like the fact that you've reduced the number of flags directly
involved in the transform from three to one.
I think your organization would require some extra knowledge in
something like Input2Input to track which
First, I agree that we could use a better name for the first flag, for example:
unwrapped or subjectToWrapping
true: the parameters are child elements of the wrapper (doc-lit-wrapper
or RPC wrapper)
false: the parameter is already a wrapper element ((doc-lit-wrapper or
RPC
Just to be clear.. I meant that I exported and ran the latest:
http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/wrapped/samples/extending-tuscany/implementation-sample/
and it worked fine without having to modify the 'sourceBare' check in
the Input2Input transformer...
Just would
On 01/24/2011 08:04 AM, Scott Kurz wrote:
Just to be clear.. I meant that I exported and ran the latest:
http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/wrapped/samples/extending-tuscany/implementation-sample/
and it worked fine without having to modify the 'sourceBare' check in
It's intentional...
This is the unwrapped type (wrapperStyle=false), but we define a
source-databinding wrapper (non-null) to help us transform to the
wrapped type.
Though the names aren't the best.. I don't think it's too bad until we
added the 'sourceBare' to the mix.
I think Raymond added
Having contributed such insight .. can I ask, Sebastien, how can I
recreate what you saw?
I just checked out that module in your sandbox and it all ran fine
without having to tweak any of the runtime code.
Thanks,
Scott
On 01/14/2011 01:08 PM, Scott Kurz wrote:
I haven't had time to try this in the past couple days, but, before
the week ends I'll just suggest a sketch of what I had in mind along
the lines of Simon's last response:
- creating a new isBareStyle() method on Operation, defaulting to 'false'
-
I haven't had time to try this in the past couple days, but, before
the week ends I'll just suggest a sketch of what I had in mind along
the lines of Simon's last response:
- creating a new isBareStyle() method on Operation, defaulting to 'false'
- setting the underlying boolean to 'true' in
On 01/11/2011 07:33 PM, Jean-Sebastien Delfino wrote:
On 01/11/2011 08:57 AM, Simon Laws wrote:
Sorry that my example wasn't clear. I had set up the following
composite...
composite xmlns=http://docs.oasis-open.org/ns/opencsa/sca/200912;
xmlns:t=http://tuscany.apache.org/xmlns/sca/1.1;
Sorry that my example wasn't clear. I had set up the following composite...
composite xmlns=http://docs.oasis-open.org/ns/opencsa/sca/200912;
xmlns:t=http://tuscany.apache.org/xmlns/sca/1.1;
targetNamespace=http://test;
name=testnativeasyncbare
component
On 01/11/2011 08:57 AM, Simon Laws wrote:
Sorry that my example wasn't clear. I had set up the following composite...
composite xmlns=http://docs.oasis-open.org/ns/opencsa/sca/200912;
xmlns:t=http://tuscany.apache.org/xmlns/sca/1.1;
targetNamespace=http://test;
On 01/10/2011 07:26 AM, Simon Laws wrote:
On Fri, Jan 7, 2011 at 6:45 PM, Jean-Sebastien Delfino
jsdelf...@apache.org wrote:
On 01/07/2011 09:44 AM, Raymond Feng wrote:
I understand your case now:
1) You have a componentType reference interface contract which is the
doc-literal WSDL.
2) You
On 01/10/2011 11:21 AM, Jean-Sebastien Delfino wrote:
OK I checked some code in at revision: 1057230 [1] . As I've been
updating the async support I extended the async part of the
implementation extension sample to have an implementation that uses a
doc/lit implementation reference but with a
On 1/10/2011 2:07 PM, Jean-Sebastien Delfino wrote:
On 01/10/2011 12:19 PM, Jean-Sebastien Delfino wrote:
On 01/10/2011 11:21 AM, Jean-Sebastien Delfino wrote:
OK I checked some code in at revision: 1057230 [1] . As I've been
updating the async support I extended the async part of the
Ben,
I haven't caught up on this thread, and would like to, but no, that
code is not in error.
On Mon, Jan 10, 2011 at 8:15 PM, Benjamin Busjaeger
busjae...@googlemail.com wrote:
In which case would both sourceWrapped and sourceBare be false?
This would typically be the case for a Java
Sebastien,
It looks like what is happening is that the transform being set up is
from a WSDL IC to a Java IC... which doesn't sound like what you
intended originally.
The WSDL IC holding the source op corresponds to the WelloTest 'upper'
reference, which you wanted.
However I think the target
Simon,
I'd be interested in taking a look at your test..
Scott
On 01/07/2011 06:41 AM, Simon Laws wrote:
My question is what happens in the invocation chain between the
ImplementationProvider holding my component reference (not-wrapped) and the
ReferenceBindingProvider of the binding configured on that component
reference (wrapped).
Can I rely on the
I understand your case now:
1) You have a componentType reference interface contract which is the
doc-literal WSDL.
2) You configure the reference binding interface contract to be
doc-literal-wrapper WSDL.
What databinding do you configure for 1 and 2?
What payload do you have for the request
On 01/07/2011 09:44 AM, Raymond Feng wrote:
I understand your case now:
1) You have a componentType reference interface contract which is the
doc-literal WSDL.
2) You configure the reference binding interface contract to be
doc-literal-wrapper WSDL.
Correct
What databinding do you
The first WSDL is document-literal style, but it is not WS-I compliant as it
has more than more child elements (two parts) for the soap:Body. You will
end-up with the following message (please note the operation is not in the
message at all).
soap:envelope
soap:body
symbolIBM/symbol
On 01/06/2011 09:32 AM, Raymond Feng wrote:
The first WSDL is document-literal style, but it is not WS-I compliant as it
has more than more child elements (two parts) for the soap:Body. You will
end-up with the following message (please note the operation is not in the
message at all).
Say I have the following WSDL operation, with one WSDL message part per
parameter, on an SCA reference:
message name=getQuoteRequest
part name=symbol ...
part name=time ...
/message
portType ...
operation name=getQuote ...
input message=getQuoteRequest ...
...
/operation
Can I use the
27 matches
Mail list logo
