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://lresende.blogspot.com/
