'automating' (ha) JAX-RPC TCK

[bu...@us.ibm.com]

Sam, once you're done with the SAAJ TCK, you'll want to tackle the JAX-RPC
TCK.  Here's a rough (and probably a bit shaky) set of things I do to run
the TCK:
1.  Set up the environment according to the TCK docs.  In particular, you
should use this jaxrpctck/bin/(See attached file: ts.jte), and you may want
to use my jaxrpctck/bin/(See attached file: ts_env.bat) as a basis for
yours.
2.  Unzip(See attached file: jaxrpctck.axis.zip) so that you end up with an
axis directory inside jaxrpctck.
3.  Make sure your CLASSPATH includes:  jaxrpctck/lib/harness.jar,
jaxrpctck/lib/javatest.jar, jaxrpctck/classes
4.  Make sure axis is in your tomcat/webapps directory.  Make sure you have
"j2ee j2ee" and "javajoe javajoe" in your users.lst file.
5.  cd jaxrpctck/axis/bin
6.  run w2jall.bat - note that this (and j2wall.bat) are intended to be run
ONCE.  Running them multiple times mostly works, though.  In particular,
they copy jaxrpctck/dist-vi/XXX.jar to XXX.jar.orig and rejar XXX.jar.  A
successive run will start with the NEW XXX.jar, not the original.  Minor
detail, but probably something you'll want to fix in your scripts.
7.  run j2wall.bat - note that some tests - J2WInheritedInterfaces,
J2WMultiInterfaceTest, Handler - require us to generate 2 WSDL files from
Java2WSDL and then merge them by hand (or in the case of Handler, to add a
service port).  The scripts generate the two WSDL files, then run vi to
stop the scripts.  You can do the merge yourself or you can copy the wsdl
from jaxrpctck/axis/dist-vi/J2WXXX/YYY.WSDL to jaxrpctck/dist-vi/J2WXXX/.
Just before he went on vacation, Rich added functionality to Java2WSDL so
that I THINK this step can be automated - you can now give Java2WSDL a WSDL
you want new stuff to be added to (--input <wsdl>) - but I haven't tried
this variation.
8.  Start tomcat
9.  cd jaxrpctck/deploy-save - the deploy directory contains the generated
deploy files.  deploy-save contains variations of these.  One problem is
that the TCK names a number of services the same, like Hello.  Since we
can't have that, we had to go in and physically change the wsdd files.
Another issue:  the generated deploy.wsdd assumes a generated impl is the
service, but we have to change that to the TCK impl.
10.  run ../bin/adminAll.ksh - J2WAttachmentsTest.deploy.wsdd will fail
because, since attachments aren't implemented yet, we haven't generated the
code for this test.
11.  Run the TCK.  This never works the first time for me.  I usually have
to do some extra tweaking, usually because I forgot something.  But if all
goes well, you should be left with only 2 failures:
ee/j2w/attachmentstest, ee/j2w/inheritedinterfacestest.  If you're really
lucky, you won't have the inheritedinterfacestest failure and you won't
have to recompile its Client.java file like I do.

These steps tell you the 'what', not the 'why', so if something goes wrong,
this won't help much in answering your questions.  But if you're really
really lucky, nothing will go rong.

Russell Butek
butek@us.ibm.com