On 9/20/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 9/20/06, ant elder <[EMAIL PROTECTED]> wrote: > > Is it worth also trying to do some interop testing of script language > composites across the Java and C++ runtimes now that we have script > languages supported by both? Something like having some > Ruby/Python/JavaScript composites which can be used in either the C++ or > Java runtimes? I'd help with the Java runtime side if others think this > would be useful. > > ...ant > > On 9/18/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > I was talking with Andy offline about re-running the cross language > > interop > > tests. I've recently made some updates to the schema while testing with > > PHP > > SDO so I copied the updates back to Tuscany/Interop. There is a patch > > attached to http://issues.apache.org/jira/browse/TUSCANY-730. There is > > also > > a WSDL file in there that exposes an operation for each interop schema > > taking that schema as input and returning it as output. I'm going to > work > > with Andy to implement a client/service in C++ so that we can test the > SDO > > binding for Axis. When Raymond is done with the new databindings code > for > > M2 > > we could do the same for Java and between Java and C++. > > > > What we could do with in C++ is an XML comparison utility. Anyone come > > across one? > > > > Simon > > > > > I think this would be a good idea. The cross language test we have done to > date have been focused on the SDO support for XML so clearly that can work > in Java, C++ and PHP components where we have SDO implementations. Sorting > out tests for the other componente types that perhaps don't support SDO yet > but would benefit from 1/ testing that the same script works in both Java > and C++ runtimes 2/ testing that messages of various formats can be passed > successfully from/to the component seems like an excellent idea. The last time I checked the Python C++ extension used a C++ interface definition style but I haven't looked closely enough to see how it handles complex types. I'm also assuming that this will change in the future if it hasn't laready changed. Andy?
It has changed now - we now have an interface.python extension that is empty as no interface definition is required for python components. E.g. the .componentType file has a definition like: <componentType xmlns="http://www.osoa.org/xmlns/sca/1.0";> <service name="CalculatorService"> <interface.python/> </service> <reference name="divideService"> <interface.python/> </reference> </componentType> There will be some work going on to remove the requirement for a .componentType file at all as the information required is all inside the .composite file. Andy
