[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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) / 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.
Re: [jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
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-tabpanelfocusedCommentId=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.
[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597382#action_12597382 ] Simon Nash commented on TUSCANY-2324: - Disclaimer: I haven't yet looked at the code. I think the interface contract on the outer reference should be used for the WS binding. According to the spec rules, it must provide a compatible subset of operations on the interface for the inner reference. If the generated WSDL doesn't match the actual WSDL, this suggests that the interfaces are not compatible, which would violate the spec and should be diagnosed as an error. There's a JIRA (TUSCANY-2109) already open for what looks like a very similar problem caused by namespace conflicts between the two interfaces. It may be possible to close this JIRA as a duplicate of TUSCANY-2109. 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) / 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.
