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.
>
