Thanks for replying but don't worry now as this has been fixed by Simon in
r773103 to fix the CompositeActivatorImpl2.getInterfaceContract problem.
Though now the PassByValueInterceptor is added to the chain instead of the
second DataTransformationInterceptor which is unnecessary. Interestingly
line 154 in DataBindingRuntimeWireProcessor it says:
// assume pass-by-values copies are required if interfaces
are remotable and there is no data binding
// transformation, i.e. a transformation will result in a
copy so another pass-by-value copy is unnecessary
so it knows it shouldn't be adding the PassByValueInterceptor but there
doesn't appear to be any code to do what the comment says. There's an
existing JIRA related to this TUSCANY-2586 so i've added a comment about
this to that.
...ant
On Fri, May 8, 2009 at 5:50 PM, Raymond Feng <[email protected]> wrote:
> This could happen for the binding.sca local invocation case where the
> reference invocation chain is directly connected to the service invocation
> chain. For example, we have a Java component uses JAXB talking the BPEL
> component that requires DOM. The data transformation path is typically
JAXB
> --> reference binding and then service binding --> DOM. But for this case,
> the binding.sca is short-circuited and the transformation should be just
> JAXB --> DOM.
>
> What RuntimeWire do we have in this case?
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Simon Laws" <[email protected]>
> Sent: Friday, May 08, 2009 9:01 AM
> To: <[email protected]>; <[email protected]>
> Subject: Re: DataTransformationInterceptor running twice
>
>> On Fri, May 8, 2009 at 4:59 PM, ant elder <[email protected]> wrote:
>>>
>>> Another issue with the helloworld-bpel sample is that the
>>> DataTransformationInterceptor gets inserted twice so twice transforms
>>> the request twice which screws it up. The problem is caused because
>>> DataBindingRuntimeWireProcessor inserts the
>>> DataTransformationInterceptor either side of the SCABindingInvoker,
>>> once in the "service.interface" phase and again in the
>>> "reference.interface". Not sure what the best fix for that is, the
>>> DataBindingRuntimeWireProcessor needs to know that the second
>>> shouldn't be used the other side of SCABindingInvoker.
>>>
>>> ...ant
>>>
>>
>> It feels like something has been missed out during the wire/activation
>> refactoring. I assume this doesn't happen on 1.x
>>
>> Simon
>
>
