You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Mike Edwards (JIRA)" <tu...@ws.apache.org> on 2008/05/13 12:42:55 UTC
[jira] Created: (TUSCANY-2316) Axis2 Binding Provider does not
handle services & references with WSDL interfaces correctly
Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
-------------------------------------------------------------------------------------------
Key: TUSCANY-2316
URL: https://issues.apache.org/jira/browse/TUSCANY-2316
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.2
Environment: - any -
Reporter: Mike Edwards
Assignee: Mike Edwards
Fix For: Java-SCA-Next
Attachments: sample-helloworld-bpel-ws.zip
Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked.
The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use.
I've attached a sample application that I created which found this problem
--
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-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, May 14, 2008 at 2:07 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Scott Kurz wrote:
>>
>> Oh, I see what I was confused about.
>>
>> The WebServiceBindingImpl object is not going to have an IC in your case
>> in
>> which you simply declare an empty element:
>> <binding.ws/>
>>
>> It is in fact, going to set the IC from the component ref/srvc IC. For
>> some reason I had it in my had that things worked differently, but
>> now I see why the clone is needed.
>>
>> Thanks for talking me through that...
>> Scott
>
> Sorry, Scott, I should have made it clear that when that code executes, the
> wsBinding has a null IC - Luciano has explained this clearly now. The code
> did not deal with the null IC correctly and this caused the initial problem
> here.
>
> As Luciano explained in another thread, there were then 2 other problems in
> the data path from the Axis binding to the BPEL process. Luciano fixed
> those to enable BPEL over WS-* to work, but I think there are deeper issues
> to look at for both those fixes - eg why does the databinding code generate
> different DOM trees depending on the path through the code?
>
>
Totally agree here, that's why I left the JIRAs opened.
> Yours, Mike.
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Raymond Feng <en...@gmail.com>.
Hi, Mike,
I have fixed the DOM transformation issue (TUSCANY-2321) under r656747.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Wednesday, May 14, 2008 2:07 PM
To: <tu...@ws.apache.org>
Subject: Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does
not handle services & references with WSDL interfaces correctly
> Scott Kurz wrote:
>> Oh, I see what I was confused about.
>>
>> The WebServiceBindingImpl object is not going to have an IC in your case
>> in
>> which you simply declare an empty element:
>> <binding.ws/>
>>
>> It is in fact, going to set the IC from the component ref/srvc IC. For
>> some reason I had it in my had that things worked differently, but
>> now I see why the clone is needed.
>>
>> Thanks for talking me through that...
>> Scott
>
> Sorry, Scott, I should have made it clear that when that code executes,
> the wsBinding has a null IC - Luciano has explained this clearly now. The
> code did not deal with the null IC correctly and this caused the initial
> problem here.
>
> As Luciano explained in another thread, there were then 2 other problems
> in the data path from the Axis binding to the BPEL process. Luciano fixed
> those to enable BPEL over WS-* to work, but I think there are deeper
> issues to look at for both those fixes - eg why does the databinding code
> generate different DOM trees depending on the path through the code?
>
>
> Yours, Mike.
>
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does
not handle services & references with WSDL interfaces correctly
Posted by Mike Edwards <mi...@gmail.com>.
Scott Kurz wrote:
> Oh, I see what I was confused about.
>
> The WebServiceBindingImpl object is not going to have an IC in your case in
> which you simply declare an empty element:
> <binding.ws/>
>
> It is in fact, going to set the IC from the component ref/srvc IC. For
> some reason I had it in my had that things worked differently, but
> now I see why the clone is needed.
>
> Thanks for talking me through that...
> Scott
Sorry, Scott, I should have made it clear that when that code executes, the wsBinding has a null IC
- Luciano has explained this clearly now. The code did not deal with the null IC correctly and this
caused the initial problem here.
As Luciano explained in another thread, there were then 2 other problems in the data path from the
Axis binding to the BPEL process. Luciano fixed those to enable BPEL over WS-* to work, but I think
there are deeper issues to look at for both those fixes - eg why does the databinding code generate
different DOM trees depending on the path through the code?
Yours, Mike.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Scott Kurz <sc...@gmail.com>.
Oh, I see what I was confused about.
The WebServiceBindingImpl object is not going to have an IC in your case in
which you simply declare an empty element:
<binding.ws/>
It is in fact, going to set the IC from the component ref/srvc IC. For
some reason I had it in my had that things worked differently, but
now I see why the clone is needed.
Thanks for talking me through that...
Scott
On Wed, May 14, 2008 at 1:58 PM, Luciano Resende <lu...@gmail.com>
wrote:
> This is all happening on the Axis2ServiceBindingProvider constructor,
> and I assume that at this point the resolve method you mentioned has
> not been trigerred yet. Note that when java interface is used, we
> properly handle it, but we were not handling it when a WSDl interface
> was in use. Below is the code with a local update to clone the
> interface contract that seems to workaround/fix the issue. Maybe I
> should use the code from resolve to properly fix this.
>
> InterfaceContract contract = wsBinding.getBindingInterfaceContract();
> if (contract == null) {
> contract =
> service.getInterfaceContract().makeUnidirectional(false);
> if ((contract instanceof JavaInterfaceContract)) {
> contract =
>
> Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
> requiresSOAP12(wsBinding));
> } else {
> //WORKAROUND/FIX for TUSCANY-2316
> try {
> contract = (InterfaceContract) contract.clone();
> } catch (Exception e) {
> //ignore
> }
> }
> wsBinding.setBindingInterfaceContract(contract);
> }
>
> .....
>
> // Set to use the Axiom data binding
> contract.getInterface().resetDataBinding(OMElement.class.getName());
>
>
> On Wed, May 14, 2008 at 7:45 AM, Scott Kurz <sc...@gmail.com> wrote:
> > Mike,
> >
> > On Wed, May 14, 2008 at 9:41 AM, Mike Edwards <
> > mike.edwards.inglenook@gmail.com> wrote:
> >
> >> Scott,
> >>
> >> Glad you've taken this out of the JIRA comments and on to the list -
> >> easier to communicate this way ;-).
> >>
> >> The point about the original code in Axis2ReferenceBindingProvider and
> >> Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
> >> InterfaceContract for the Axis binding itself - separate from the
> >> InterfaceContract of the BPEL component. The wire, when it is created
> must
> >> be able to see the databinding for the BPEL process (DOM) and the
> separate
> >> databinding for the Axis binding code (OMElements) and then generate the
> >> appropriate conversions between the two.
> >>
> >
> >> The current code in Axis2ReferenceBindingProvider and
> >> Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract,
> it
> >> does not create a separate InterfaceContract for the Axis binding - it
> >> simply hands over the one from the BPEL Process. When the Axis binding
> does
> >> some updates, in particular for the databinding used, it simply
> overwrites
> >> the BPEL Process information. This causes the databinding conversion
> code
> >> to assume that no transformation is necessary and as a result, the wrong
> >> stuff gets delivered. Result: BANG! - some nasty type conversion
> failure
> >> at a random point in the code.
> >>
> >
> > Yes there is supposed to be a distinct IC between the wireSource IC
> (Axis2
> > binding IC) and the wireTarget IC (where the target is the
> BPEL-implemented
> > component). But are we sure the problem is with the binding side and
> not
> > the impl side?
> >
> > Look at what the Axis2 binding code does:
> >
> > public Axis2ServiceBindingProvider(RuntimeComponent component,.....)
> > ....
> > InterfaceContract contract =
> > wsBinding.getBindingInterfaceContract();
> >
> > It just gets the IC from the WS binding.
> >
> > From what you're saying, it sounds like this IC obtained from the binding
> is
> > somehow in the picture as the wireTarget IC as well. This is what
> > surprises me, because if we look at the WS binding resolve() method, we
> seem
> > to be creating a brand new IC at this point:
> >
> > WebServiceBindingProcessor.resolve():
> > .....
> > PortType portType = getPortType(model);
> > if (portType != null) {
> > WSDLInterfaceContract interfaceContract =
> > wsdlFactory.createWSDLInterfaceContract();
> > WSDLInterface wsdlInterface;
> > try {
> > wsdlInterface =
> > wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
> > } catch (InvalidInterfaceException e) {
> > throw new ContributionResolveException(e);
> > }
> > interfaceContract.setInterface(wsdlInterface);
> > model.setBindingInterfaceContract(interfaceContract);
> > }
> >
> > I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
> > methods use a cache but rather instantiate new objects.
> >
> > I would think that for a component service with intf.wsdl we would be
> > building a distinct IC which would become the wireTarget IC, and just am
> > trying to understand how changing the DB of the source IC (binding IC) in
> > this case can present a problem.
> >
> >
> >> I'd have submitted a fix by now if I had not found yet another bug
> lurking
> >> behind this one....
> >> I want to get my Sample code for BPEL process exposed as a Webservice
> >> working before I commit a fix.
> >>
> >>
> >> Yours, Mike.
> >>
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Luciano Resende <lu...@gmail.com>.
This is all happening on the Axis2ServiceBindingProvider constructor,
and I assume that at this point the resolve method you mentioned has
not been trigerred yet. Note that when java interface is used, we
properly handle it, but we were not handling it when a WSDl interface
was in use. Below is the code with a local update to clone the
interface contract that seems to workaround/fix the issue. Maybe I
should use the code from resolve to properly fix this.
InterfaceContract contract = wsBinding.getBindingInterfaceContract();
if (contract == null) {
contract = service.getInterfaceContract().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
} else {
//WORKAROUND/FIX for TUSCANY-2316
try {
contract = (InterfaceContract) contract.clone();
} catch (Exception e) {
//ignore
}
}
wsBinding.setBindingInterfaceContract(contract);
}
.....
// Set to use the Axiom data binding
contract.getInterface().resetDataBinding(OMElement.class.getName());
On Wed, May 14, 2008 at 7:45 AM, Scott Kurz <sc...@gmail.com> wrote:
> Mike,
>
> On Wed, May 14, 2008 at 9:41 AM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
>> Scott,
>>
>> Glad you've taken this out of the JIRA comments and on to the list -
>> easier to communicate this way ;-).
>>
>> The point about the original code in Axis2ReferenceBindingProvider and
>> Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
>> InterfaceContract for the Axis binding itself - separate from the
>> InterfaceContract of the BPEL component. The wire, when it is created must
>> be able to see the databinding for the BPEL process (DOM) and the separate
>> databinding for the Axis binding code (OMElements) and then generate the
>> appropriate conversions between the two.
>>
>
>> The current code in Axis2ReferenceBindingProvider and
>> Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract, it
>> does not create a separate InterfaceContract for the Axis binding - it
>> simply hands over the one from the BPEL Process. When the Axis binding does
>> some updates, in particular for the databinding used, it simply overwrites
>> the BPEL Process information. This causes the databinding conversion code
>> to assume that no transformation is necessary and as a result, the wrong
>> stuff gets delivered. Result: BANG! - some nasty type conversion failure
>> at a random point in the code.
>>
>
> Yes there is supposed to be a distinct IC between the wireSource IC (Axis2
> binding IC) and the wireTarget IC (where the target is the BPEL-implemented
> component). But are we sure the problem is with the binding side and not
> the impl side?
>
> Look at what the Axis2 binding code does:
>
> public Axis2ServiceBindingProvider(RuntimeComponent component,.....)
> ....
> InterfaceContract contract =
> wsBinding.getBindingInterfaceContract();
>
> It just gets the IC from the WS binding.
>
> From what you're saying, it sounds like this IC obtained from the binding is
> somehow in the picture as the wireTarget IC as well. This is what
> surprises me, because if we look at the WS binding resolve() method, we seem
> to be creating a brand new IC at this point:
>
> WebServiceBindingProcessor.resolve():
> .....
> PortType portType = getPortType(model);
> if (portType != null) {
> WSDLInterfaceContract interfaceContract =
> wsdlFactory.createWSDLInterfaceContract();
> WSDLInterface wsdlInterface;
> try {
> wsdlInterface =
> wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
> } catch (InvalidInterfaceException e) {
> throw new ContributionResolveException(e);
> }
> interfaceContract.setInterface(wsdlInterface);
> model.setBindingInterfaceContract(interfaceContract);
> }
>
> I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
> methods use a cache but rather instantiate new objects.
>
> I would think that for a component service with intf.wsdl we would be
> building a distinct IC which would become the wireTarget IC, and just am
> trying to understand how changing the DB of the source IC (binding IC) in
> this case can present a problem.
>
>
>> I'd have submitted a fix by now if I had not found yet another bug lurking
>> behind this one....
>> I want to get my Sample code for BPEL process exposed as a Webservice
>> working before I commit a fix.
>>
>>
>> Yours, Mike.
>>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Scott Kurz <sc...@gmail.com>.
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Scott,
>
> Glad you've taken this out of the JIRA comments and on to the list -
> easier to communicate this way ;-).
>
> The point about the original code in Axis2ReferenceBindingProvider and
> Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
> InterfaceContract for the Axis binding itself - separate from the
> InterfaceContract of the BPEL component. The wire, when it is created must
> be able to see the databinding for the BPEL process (DOM) and the separate
> databinding for the Axis binding code (OMElements) and then generate the
> appropriate conversions between the two.
>
> The current code in Axis2ReferenceBindingProvider and
> Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract, it
> does not create a separate InterfaceContract for the Axis binding - it
> simply hands over the one from the BPEL Process. When the Axis binding does
> some updates, in particular for the databinding used, it simply overwrites
> the BPEL Process information. This causes the databinding conversion code
> to assume that no transformation is necessary and as a result, the wrong
> stuff gets delivered. Result: BANG! - some nasty type conversion failure
> at a random point in the code.
>
Yes there is supposed to be a distinct IC between the wireSource IC (Axis2
binding IC) and the wireTarget IC (where the target is the BPEL-implemented
component). But are we sure the problem is with the binding side and not
the impl side?
Look at what the Axis2 binding code does:
public Axis2ServiceBindingProvider(RuntimeComponent component,.....)
....
InterfaceContract contract =
wsBinding.getBindingInterfaceContract();
It just gets the IC from the WS binding.
>From what you're saying, it sounds like this IC obtained from the binding is
somehow in the picture as the wireTarget IC as well. This is what
surprises me, because if we look at the WS binding resolve() method, we seem
to be creating a brand new IC at this point:
WebServiceBindingProcessor.resolve():
.....
PortType portType = getPortType(model);
if (portType != null) {
WSDLInterfaceContract interfaceContract =
wsdlFactory.createWSDLInterfaceContract();
WSDLInterface wsdlInterface;
try {
wsdlInterface =
wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
} catch (InvalidInterfaceException e) {
throw new ContributionResolveException(e);
}
interfaceContract.setInterface(wsdlInterface);
model.setBindingInterfaceContract(interfaceContract);
}
I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
methods use a cache but rather instantiate new objects.
I would think that for a component service with intf.wsdl we would be
building a distinct IC which would become the wireTarget IC, and just am
trying to understand how changing the DB of the source IC (binding IC) in
this case can present a problem.
> I'd have submitted a fix by now if I had not found yet another bug lurking
> behind this one....
> I want to get my Sample code for BPEL process exposed as a Webservice
> working before I commit a fix.
>
>
> Yours, Mike.
>
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does
not handle services & references with WSDL interfaces correctly
Posted by Mike Edwards <mi...@gmail.com>.
Scott Kurz wrote:
> Mike,
>
> Just trying to use this issue to test/expand my own understanding of the
> Tuscany databinding framework.
>
> You're saying there's a problem with setting (resetting) the Axiom DB on the
> IC obtained from the WebServiceBindingImpl. I'm just trying to understand
> what the problem could be.
>
> What second purpose could this particular IC be serving that you need to
> clone the original and only set the Axiom DB on a cloned copy?
>
> Say we look at the DataBindingRuntimeWireProcessor processing and we are
> looking at the service-side Axis2 binding, where the wireSource IC is then
> the Axis2 binding IC and the wireTarget IC is a BPEL impl IC.
>
> So what side effect is happening in setting the wireSource IC with the Axiom
> DB? It seems the wireTarget side of the question should be built off a
> completely separate IC object... even though this IC is also built off the
> same WSDL file, I'd think distinct objects should be created and you
> wouldn't need a clone.
>
>
> Scott
>
Scott,
Glad you've taken this out of the JIRA comments and on to the list - easier to communicate this way ;-).
The point about the original code in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider
is that there is SUPPOSED to be a new InterfaceContract for the Axis binding itself - separate from
the InterfaceContract of the BPEL component. The wire, when it is created must be able to see the
databinding for the BPEL process (DOM) and the separate databinding for the Axis binding code
(OMElements) and then generate the appropriate conversions between the two.
The current code in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider is wrong since for
a WSDL InterfaceContract, it does not create a separate InterfaceContract for the Axis binding - it
simply hands over the one from the BPEL Process. When the Axis binding does some updates, in
particular for the databinding used, it simply overwrites the BPEL Process information. This causes
the databinding conversion code to assume that no transformation is necessary and as a result, the
wrong stuff gets delivered. Result: BANG! - some nasty type conversion failure at a random point
in the code.
I'd have submitted a fix by now if I had not found yet another bug lurking behind this one....
I want to get my Sample code for BPEL process exposed as a Webservice working before I commit a fix.
Yours, Mike.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
Posted by Scott Kurz <sc...@gmail.com>.
Mike,
Just trying to use this issue to test/expand my own understanding of the
Tuscany databinding framework.
You're saying there's a problem with setting (resetting) the Axiom DB on the
IC obtained from the WebServiceBindingImpl. I'm just trying to understand
what the problem could be.
What second purpose could this particular IC be serving that you need to
clone the original and only set the Axiom DB on a cloned copy?
Say we look at the DataBindingRuntimeWireProcessor processing and we are
looking at the service-side Axis2 binding, where the wireSource IC is then
the Axis2 binding IC and the wireTarget IC is a BPEL impl IC.
So what side effect is happening in setting the wireSource IC with the Axiom
DB? It seems the wireTarget side of the question should be built off a
completely separate IC object... even though this IC is also built off the
same WSDL file, I'd think distinct objects should be created and you
wouldn't need a clone.
Scott
[jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not
handle services & references with WSDL interfaces correctly
Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596503#action_12596503 ]
Scott Kurz commented on TUSCANY-2316:
-------------------------------------
The binding-ws-axis2 is overwriting the databinding on the IC obtained from the binding.ws model object (WebServiceBindingImpl). So far, that would seem to be correct, then.
What do the ClassCastExceptions you're getting look like?
> Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
> -------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2316
> URL: https://issues.apache.org/jira/browse/TUSCANY-2316
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Axis Binding Extension
> Affects Versions: Java-SCA-1.2
> Environment: - any -
> Reporter: Mike Edwards
> Assignee: Mike Edwards
> Fix For: Java-SCA-Next
>
> Attachments: sample-helloworld-bpel-ws.zip
>
>
> Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked.
> The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use.
> I've attached a sample application that I created which found this problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not
handle services & references with WSDL interfaces correctly
Posted by "Mike Edwards (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596708#action_12596708 ]
Mike Edwards commented on TUSCANY-2316:
---------------------------------------
Scott,
The ClassCastExceptions occur in the BPELInvoker.createInvocationMessage(...) method and are caused by that code being delivered message arguments that are not the DOM Elements that it expects.
The InterfaceContract overwrite means that Axis2 related OMElements are delivered.
Fixing the InterfaceContract overwrite in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider (by cloning the Interface...) then reveals a second problem, this time associated with the DataBinding code.
The DataBinding code converting from OMElements to DOM generates a message which has a Document root element, while the code in createInvocationMessage expects only the internal Element elements. The simplest fix for this is to modify the createInvocationMessage code to strip off the Document element, if there is one.
Doing this then reveals yet another problem, this time with the exact form of the elements in the DOM tree passed in from the DataBinding code - this causes an exception within the ODE BPEL server code. Still investigating that one with Luciano....
> Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
> -------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2316
> URL: https://issues.apache.org/jira/browse/TUSCANY-2316
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Axis Binding Extension
> Affects Versions: Java-SCA-1.2
> Environment: - any -
> Reporter: Mike Edwards
> Assignee: Mike Edwards
> Fix For: Java-SCA-Next
>
> Attachments: sample-helloworld-bpel-ws.zip
>
>
> Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked.
> The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use.
> I've attached a sample application that I created which found this problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2316) Axis2 Binding Provider does not
handle services & references with WSDL interfaces correctly
Posted by "Mike Edwards (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Edwards updated TUSCANY-2316:
----------------------------------
Attachment: sample-helloworld-bpel-ws.zip
Sample BPEL application which exposes the BPEL component as a Web service
> Axis2 Binding Provider does not handle services & references with WSDL interfaces correctly
> -------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2316
> URL: https://issues.apache.org/jira/browse/TUSCANY-2316
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Axis Binding Extension
> Affects Versions: Java-SCA-1.2
> Environment: - any -
> Reporter: Mike Edwards
> Assignee: Mike Edwards
> Fix For: Java-SCA-Next
>
> Attachments: sample-helloworld-bpel-ws.zip
>
>
> Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked.
> The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use.
> I've attached a sample application that I created which found this problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.