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 :)
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)
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).
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...
Regards
Simon
