axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: xml-axis-wsif/java/doc run.htm
Date Fri, 18 Oct 2002 14:20:05 GMT
whitlock    2002/10/18 07:20:05

  Modified:    java/doc run.htm
  Added unit test description
  Revision  Changes    Path
  1.2       +70 -2     xml-axis-wsif/java/doc/run.htm
  Index: run.htm
  RCS file: /home/cvs/xml-axis-wsif/java/doc/run.htm,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- run.htm	14 Oct 2002 16:47:53 -0000	1.1
  +++ run.htm	18 Oct 2002 14:20:05 -0000	1.2
  @@ -13,9 +13,77 @@
  -TBW: general information about tests, junit and how to run them
  +WSIF has a number of unit tests found in the tests directory. These use Junit (currently
Junit 3.7).
  +WSIF unit tests are loosely themed and test function in multiple providers. For instance

  +jms.JmsTest tests jms:address, jms:property and jms:propertyValue tags across the SoapJms,

  +AxisJms and NativeJms providers. You can either run a specific unit test or run all of
them by 
  +running util.WSIFTestRunner. has 
  +which allows you to switch off areas across all unit tests. So because I rarely change
the EJB provider, 
  +I run with ejb=off so when I run WSIFTestRunner none of the EJB tests get run. This can
be dangerous 
  +and it is generally better to run all the unit tests. Individual unit tests can call 
  +TestUtilities.areWeTesting("ejb") for instance. There are various listeners needed to run
the unit 
  +tests (JMS2HTTPBridge, JMSAsyncListener, NativeJMSRequestListener) and unit tests automatically
  +and stop the listeners that they need. All the tests need to find WSDL and other files
on the 
  +local filesystem. This is done by looking for the WSIF src, samples and tests directories
  +the directory specified by the wsif.path property in So I have wsif.path=c:\\wsif.
  +The setup required to run the unit tests is based on the various providers being used.
  +For Soap and Axis over Http, find all files called DeploymentDescriptor.xml in the samples
and tests
  +directories and deploy them to your favourite web server. The web server must be running
on your 
  +localhost using port 8080. In the future localhost:8080 should be a property loaded from

  +wsif.test.propeerties. The level of soap or axis used on your 
  +server does not have to be the same as the level used by WSIF. I use soap 2.2 on tomcat
so I issue
  +java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter
deploy "samples\services\addressbook\DeploymentDescriptor.xml"
  +There is no setup to do to run tests under the Java provider.
  +To run tests using the EJB provider, ... todo ???
  +There are three providers that are enabled for Jms : Soap, Axis and NativeJms. Asynchronous
support is 
  +currently only supported over Jms, so to test out async you need Jms. Obviously you need
a Jms 
  +implementation. WSIF uses JNDI to lookup Jms queues and queue connnection factories. Topics
  +not supported at the moment. The batch files samples\wsifjmssetup.bat and samples\wsifjmstidy.bat
  +and delete the JNDI definitions for the Jms queues and queue connection factory needed
to run the samples 
  +and some of the unit tests. I use IBM MQSeries as my Jms implementation so the batch files

  +samples\wsifmqsetup.bat and samples\wsifmqtidy.bat create and delete the MQSeries queues
needed to 
  +run the samples and some of the unit tests. The batch files tests\wsiftestjmssetup.bat
and tests\wsiftestmqsetup.bat create the 
  +JNDI definitions and the MQSeries queues needed to run the unit tests. No code in WSIF
or in the unit
  +tests is MQ-specific, except for these mq batch files and WSIFJMSFinderForMq. The unit
tests also
  +assume the local queue manager is being used. The unit tests also assume that the JNDI
database is on
  +the filesystem in \JNDI-Directory.
  +WSIF provides a JMS2HTTPBridge which takes soap messages from a Jms queue, routes them
to a url and sends
  +the response message back to a replyTo queue. The JMS2HTTPBridge is intended as a test
tool only.
  +So unit tests that test SoapJms and AxisJms start the JMS2HTTPBridge automatically. NativeJms
  +are served by the NativeJMSRequestListener which implements the backend service for our
unit tests.
  +Specifying remotewsdl=on in wsif.test.components will enable the tests in the wsdl package
to be run. These
  +tests test out loading wsdl from a url, from a jar file and test out imports. So you need

  +wsdl\ClassLoaderTest.jar on your classpath, and http://localhost:8080/wsdl/AddressBook.wsdl
  +to be available.
  +The intention is for all unit tests to be run by WSIFTestRunner so everyone runs them all
  +Unfortunately there are a few tests which cannot be run in this way (or rather I could
not make them 
  +run automatically). An example of this is the translated.messages tests, because these
need to set the
  +locale, and I could not reset the locale multiple times in the same test.
  +The intention is for everyone to make sure that all the unit tests are kept working all
the time, so
  +no regressions find their way in. If you add in new code (or even fixes) into WSIF, please
add in new
  +unit tests, or extend existing tests to cover the new code you've added. Otherwise tomorrow
  +may unknowingly break your code. If you add in new unit tests please add them to WSIFTestRunner
  +that everyone will automatically run them as well. I guess when you make a change that
requires a 
  +service to be redeployed or a queue definition to be added or changed, please notify everyone
  +axis-dev so that everyone can update their setup.

View raw message