Simon,
I originally noticed this problem by inspecting trace, and I'm still looking
for an idea how to test this.
The reason it's difficult is interesting.
I thought I'd just take a WS, grab the WSDL, declare it via <interface.wsdl>
on the outer reference,
and have the inner Java client intf use a package that I knew would map to a
different TNS than that of the portType in the service WSDL.
This is using doc-lit-wrapped WSDL so I thought the wrapper elem with wrong
TNS in the payload would be a problem.
Though the client does send the "bad" wrapper elem in the SOAP payload, the
service (of course a Tuscany service with <binding.ws>)
handles the data just fine. Our Tuscany databinding code just realizes
that it can't convert wrapper to wrapper so it simply switches
to convert the wrapper's children.
The reason is the code in Input2InputTransformer:
...
if (sourceWrapperHandler.isInstance(sourceWrapper,
wrapperElement, childElements, context)) {
plus the OMElementWrapperHandler implementation
public boolean isInstance(...)
if (!element.getQName().equals(wrapper.getQName())) {
return false;
So, on the one hand, I thought this was interesting.
On the other, still looking for an idea to test this. Is there an easy way
to create say a raw Axis2 service hosted in the itest environment that would
not be so tolerant?
Scott
On Wed, Jun 11, 2008 at 8:54 AM, Simon Laws (JIRA) <
tuscany-dev@ws.apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604207#action_12604207]
>
> Simon Laws commented on TUSCANY-2324:
> -------------------------------------
>
> Is there a test case for this issue that shows the problem? I'm eyeballing
> the code and its interesting as the code that processes promotion on the
> reference side works differently to the code that processes promotion on the
> service side. On the reference side it only copies the bindings down. On the
> service side it does interface contracts also.
>
> > InterfaceContract is not pushed down to an inner, promoted component
> reference only with Axis2 binding
> >
> -------------------------------------------------------------------------------------------------------
> >
> > Key: TUSCANY-2324
> > URL: https://issues.apache.org/jira/browse/TUSCANY-2324
> > Project: Tuscany
> > Issue Type: Bug
> > Components: Java SCA Axis Binding Extension
> > Reporter: Scott Kurz
> > Priority: Minor
> >
> > If we take the following example where an inner component reference is
> overridden in two ways by the outer component using the inner Composite as
> impl:
> > 1) a <binding.ws> is added
> > 2) a WSDL intf (compatible with the inner Java intf) is declared
> > <composite ... name="OuterComposite">
> > <component name="OuterComponent">
> > <implementation.composite name="blah:InnerComposite"/>
> > <reference name="outerRef" target="MyTarget">
> > <interface.wsdl interface="
> http://blah#wsdl.interface(HelloWorld)<http://blah#wsdl.interface%28HelloWorld%29>"
> />
> > <binding.ws/>
> > </reference>
> > </component>
> > </composite
> > <composite .... name="InnerComposite">
> > <component name="InnerComponent">
> > <implementation.java .../>
> > <reference name="helloWorldService">
> > <interface.java
> interface="test.sca.w2j.ws.statc.exc.helloworld.HelloWorld"/>
> > </reference>
> > </component>
> > <reference name="outerRef"
> promote="InnerComponent/helloWorldService"/>
> > </composite>
> > we have a problem.
> > The CompositeActivatorImpl is going to start an
> Axis2ReferenceBindingProvider for the inner Composite ref. The WS
> binding is propagated down or inwards, you could say. But this WS binding
> has a null IC, so we're going to look at the component ref IC, but this will
> be the inner component ref IC, which is a Java IC. This kicks off a
> Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC.
> > So the generated WSDL may not match the actual WSDL, which is a problem.
> > Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the
> outer component's <binding.ws/> we would not have had a problem; it would
> have been propagated inwards along with the binding itself.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
