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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
> > Mike,
> >
> > On Wed, May 14, 2008 at 9:41 AM, Mike Edwards <
> > [EMAIL PROTECTED]> 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/
>
