[ 
https://issues.apache.org/jira/browse/TUSCANY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593385#action_12593385
 ] 

cez edited comment on TUSCANY-2280 at 4/30/08 10:36 AM:
----------------------------------------------------------------------

Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior).

Thanks in advance

      was (Author: cez):
    Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior)
  
> No data transformation for fault types
> --------------------------------------
>
>                 Key: TUSCANY-2280
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2280
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>            Reporter: Cezary Wisniewski
>             Fix For: Java-SCA-1.1, Java-SCA-1.2
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to