On 3/9/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
Hi Simon, Some comments in line... On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 3/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote: > > > > Hi Simon, > > > > Essentually, as I see it, there are two main activities: > > > > - Increase the types of data. The sample is just a trivial complex > > type, we should also test more complex data strucutres using either > (or > > both) the SDO schemas (in the CTS & SDO Impl) and the interop tests > > (which I > > think you were one of the main authors of). > > - Add tests for interop between databindings > > > > In doing so I think we now need to test different styles of ws bindings. > > Since we need to generate the wrappers for doc/lit wrapped style ws > > binding, > > it means that we should also test rpc and straight doc/lit style as they > > could effect the way databinding transformations behave. > > > > I should be adding a patch for the first interop today (or tomorrow), so > > if > > you wanted add different ws binding styles to the current example that > > would > > be a good place to start. > > > > Thanks for you offer of help, > > Dan > > > > On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote: > > > > > > > > Seems like Raymond generates the SDO representation of the wsdl as > > well > > > as > > > > the data in the the XSDs. This seems to be due to the use of wrapped > > > style > > > > of ws binding (or is it always necessary ?). Interesting thought > that > > > this > > > > is required, personally I'd not have guessed it would be needed as > I'd > > > > assumed the wsdl is the domain of (transport) bindings rather than > > > > databindings. > > > > > > > > Would like to make a couple of minor tweaks to what Raymond did > > > (generate > > > > the SDO objects in a non-default package) so we can do sdo<->jaxb > > > between > > > > client and service > > > > > > > > Thanks for helping chaps, > > > > Dan > > > > > > > > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > If you try with the very latest SVN code both the JAXB and SDO > WS > > > > tests > > > > > > should work now as Raymond made so fixes over night (works for > me > > > > now). > > > > > > > > > > > > I don't think the tests using the default binding will work > right > > > now > > > > as > > > > > > there's no default binding implemented yet. > > > > > > > > > > > > ...ant > > > > > > > > > > > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi Dan, I've just spent a couple of days stepping through the > > SCA > > > > code > > > > > > and > > > > > > > trying various tests to build up my knowledge a little. I note > > the > > > > > > > databinding tests are being updated and you are asking for > some > > > help > > > > ( > > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just > > > updated > > > > > from > > > > > > > SVN > > > > > > > (for the integration branch) and ran up your tests and get the > > > same > > > > > > > result, > > > > > > > i.e. the JAXB/WS combination passes while the other three > fails. > > > By > > > > > way > > > > > > of > > > > > > > education for me I'm going to have a crack at debugging and > see > > > how > > > > I > > > > > > get > > > > > > > one. Have you already solved this problem? Anything I should > > > > > > particularly > > > > > > > look out for in terms of configuring and debugging the tests? > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > > > > > Hi Ant > > > > > > > > > > Yes, thanks, I just discovered that. I went back and did a mvn > clean > > > and > > > > a > > > > > rebuild and now I see both the sdo and jaxb ws tests working now. > > > > > > > > > > Simon > > > > > > > > > > > > Dan > > > > > > By way of education am just digging into what gets generated and used > in > > > your sample so I will be back here with questions shortly:-) > > > > > > From your comments you have tests in mind. Clearly there are various > > > combinations of message, databinding and binding that we could test. > We > > > did > > > some work a while back on interop schema that we could use and there > is > > > all > > > the work in CTS. Can you give me a quick run down on what you plan. I > > can > > > help write tests. > > > > > > Regards > > > > > > Simon > > > > > > So let's enumerate what you have in mind > > Databindings > ========== > SDO > Static types - currently part of the test > Dynamic types - are these supported? I hope dynamic datatypes are intended to be supported, but there isn't a great deal of doco. It shouldn't be too hard to test and see... also Raymond has been doing quite a few changes recently, so you never know :) The obvious drawback of only supporting static datatypes is that it would make it harder to code generic components that, for example, might be used to provide audit trails for SOX compliancy. JAXB > etc. > > You have separated your tests according to databinding so there are > separate > JAXB and SDO tests. I assume that for cross databinding interop the > intention is to instigate a new interop tests project? This could reuse > the > components from the databinding specific tests. Absolutley, as per email posting : http://www.mail-archive.com/[email protected]/msg14623.html Binding > ===== > Axis (ws) > WSDL with various styles > doc/lit wrapped > doc/lit - is this supported? > rpc - is this supported? > Java - not working currently > JMS > JSAON-RPC > etc. > > Each databinding test has a dependency on the full range of bindings to be > tested > > Types > ===== > Person - currently doing initial tests with a single complex type > XSD from SDO tests > XSD from CTS tests > XSD from interop tests > > We could end up with a fair few XSDs. We could do with a little tool to > write the tests for us as they will all be the same apart from the > differing > types:-) Yes, a tool would be great. There is the obvious Java->WSDL and WSDL->Java tools, but a tool to automate the generation of scdl would be way cool :) I think we should consider tests that pass multiple parameters.. just incase a next() is missed :)
I'm warming to this idea. I've just added some of the interop types to the SDO test and it's a real pain to do manually and error prone. To test a new type you have to. pom - add type to generator configuration ./composite - include factory (I'm assuming that we stick with a pair of component but with lots of methods on the interface so that no rewiring is required) forwardcomponent iface - add method to use type forwardcomponent impl - add method to use type reflectcomponent iface - add method to use type reflectcomponent impl - add method to use type testclient - add call to new method and test to make sure it worked update wsdl to reflect new type and method So a pain. Rather than spend lots of time on some automatic detection and generation scheme I think we could simply knock up a piece of XML that describes Type to be tested Input XML Expected output XML (possibly with the piece of code that is dropped into the reflectcomponent to achieve it) Databinding required etc. And then drop the appropriate components, wsdl etc. from this. We would have to do slightly different things re. SDO vs JAXB but doesn't require complicated intelligence. Even if we only run this once it has to be better than doing it by hand:-) Many of these XSDs will overlap so we could probably do with a bit
> of weeding. Agreed In a previous mail in this thread you talk about adjusting > namespaces. Are we going to have to do some namespace manipulation? Both JAXB and SDO (and XMLBeans etc) use the xsd namespace as the generated java package name, so unless we map them to different namespaces we can't have both JAXB and SDO generated classes in the same classloader (since they would clash)
If we have a little tool to generate all the stuff for us we could include a mapping easily There is potential here for quite a number of combinations of test. Copying
> from your tests as they stand we would end up with something like the > following (I have renamed the components to point out that we could reuse > them in the interop case) > > itest/databindings/jaxb > <composite> > <component name="ForwardComponentWSDocLitWrapped"> > <implementation.java class="....ForwardComponentJaxbImpl"/> > .... > <reference name="ReflectComponentWSDocLitWrappedReference"/> > ... > <component name="ForwardComponentLocal"> > <implementation.java class="....ForwardComponentJaxbImpl"/> > .... > <reference name="ReflectComponentLocalReference"/> > ... > <component name="ForwardComponent..."> > <implementation.java class="....ForwardComponentJaxbImpl"/> > .... > > <service name="ReflectComponentWSDocLitWrapped"/> > ... > <reference>ReflectComponent</reference> > <service name="ReflectComponentLocalBinding"/> > ... > <reference>ReflectComponent</reference> > <component name="ReflectComponent"> > <implementation.java class="....RefelctComponentJaxbImpl"/> > .... > > Where > ForwardComponentJaxbImpl > Type1 forwardType1(Type1 data) - forward data to the component's > reference > Type2 forwardType2(Type2 data) - forward data to the component's > reference > ReflectComponentJaxbImpl > Type1 reflectType1(Type1 data) - make a change to data(?) and > return the data > Type2 reflectType2(Type2 data) - make a change to data(?) and > return the data > > ForwardComponent* and ReflectComponent are wired together with a > appropriate bindings (and jaxb databinding) > A local client calls each method in each ForwardComponent* Yep, seems like we have the same idea here... > itest/databindings/sdo > As jaxb but the types used are SDO types so new ForwardComponent* and > ReflectComponent* are built > If dynamic types are supported we need Forward and Reflect components > to > support methods for all of the static types we are interested in and a > dynamic type also. > > > itest/databindings/interop > Represents various combinations of databindings. If above we have > built > a ForwardComponent for each databinding we just reuse these and wire them > together in a chain and test that cross binding transformation works. Agreed... we could achive this by adding references to the existing composites to their peer in the different databinding test case.... It might be necessary to refactor the services, service clients etc from the individual databinding projects into another project. Each specific databinding (or interop suite) would then depend on it, and only contain the necessary test classes. The reason for this (slight change) is I that I think it might simplify managing the wsdl etc and reduce duplication in other projects. Also, it looks like the chains (of transformers, invokers etc) are wired together at contribution time, although I think (hope) that this wouldn't cause a failure to contribute, we wouldn't want the test cases to fail due this (imho).
Well I'm for anything that reduces duplication. This has potential to look over complex if we try to test many types in many combinations so anything we can do to split out components and reuse is good. I'm going to familiarize myself with the various XSDs that are available now
> (I expect the list has grown since I looked a long time ago). I can then > take a look at the different binding styles as you suggest and see what is > supported. If anyone knows of the top of their head that would be good. Agreed... Raymond / Sebastien and others, any doco pointers ? Assuming there aren't any, this looks like an important area to cover in the wiki & hopefully the doc would be valid for both the sca-java-integration and trunk...
It took a look at the WebService binding spec and it says that it should support anything that is valid in a WSDL binding so I will still go ahead and try this. I have to go and do something else for most of today but will be around intermittently. Regards
> > Simon >
