I'm (still) looking at the various JIRA related to enabling support for interface matching across the domain. I wrote a simple test [1] to compare obviously (to me) miss-matching interfaces. To my surprise it was the local variant that failed. Now the service interface here is @Remoteable. and differs in the type of the input parametner.
String foo(String str); vs String foo(ParameterObject po); The test fails because our InterfaceContractMapper thinks that these are compatible. It does this because when comparing the XMLType that is the logical type of each it finds that one has a type (string) and one is set to null. It seems that this happens because databinding can't guess at an XML type for ParameterObject and the default java Object is compatible with string. I note that the databinding string is set differently. One to java.lang.String and one to java.ComplexType. If the interface is WSDL you get different results. Presumably because the XML type is easy to determine in that case. It seems that there are some inconsistencies inside the databinding model that I hadn't considered. Can anyone tell my how the model is intended to work in this respect and what problem cases exist. Regards Simon [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/interface-matching/ -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
