axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Perry2 <>
Subject Re: Solaris and 1.3 release (Running tests)
Date Fri, 22 Oct 2004 09:21:37 GMT

The difficulty is that approach is that Ant can't easily do regular
expression matching and substitution. The files mentioned are Ant property
files so if a name is listed more than once only the last value is used.

The Ant version of the test framework was developed to fit in with the
existing framework, whilst adding the ability to specify a different host
and port, and endpoint. It also has support for automated handler tests and
runs a tcp monitor to capture the request/response conversation from the
client to the server.

The test framework design, which is basically the same for both the script
based and ant based, is limited to running each client only once per test
run without copying the wsdl, client and output file(s) to a new name and
running the same test as a different name.

The current Ant system will pass arguments -p testPort -s testHost (I know
it should be -h) to all tests unless there is an entry in the
test.endpoints property file in which case it will construct a new endpoint
form the http://$testHost:$testPort/newEndpoint. This is wrong too as it
should let the client call the default endpoint unless specifically told
otherwise. Like I said I'm currently re-structuring it to simplify the
parameters passed. I will take these comments into consideration. In the
sort term I'll change it so that tests will run call default endpoint
unless otherwise specified.

The best approach would be to have a XML file specifying client, wsdl,
endpoint, expected out file. This would more logically base the tests
around the client name and simplify the current test structure where
everything is based around the wsdl name as this would allow many clients
to use the same wsdl without having to copy the wsdl to a different name. I
feel that this would still be best implemented in Ant as it only has to be
written once, rather than as shell scripts/batch script/new platform
scripts. I have not looked into implementing this approach yet so it might
take a while.


Andrew Perry
Clients for Web Service Stack
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828  External + 44 (0)1962 819828
Fax. + 44(0)1962 818080

             22/10/2004 07:56          "Apache AXIS C Developers List"     
             Please respond to                                             
              "Apache AXIS C                                       Subject 
             Developers List"          Re: Solaris and 1.3 release         
                                       (Running tests)                     

Hi Andrew,
I have a suggestion,
> Valentin,
> I am working on the ant documentation now and will update with a draft as
> soon as possible.
> In its simplest terms you need to run ant -f test.xml -Ddir.include=<path
> to axis include directory> -Ddir.libraries=<path to axis libraries>
> -Ddir.xmlParser=<path to xml parser library, e.g. xerces>
> -Ddir.package.WSDL2Ws=<path to wsdl2ws.jar> -Ddir.axisJARs=<path to axis
> jar files> -Ddir.package.lib=<path to axis libraries>
> -DtransportLibraryName=<axis transport library to use, e.g.
> axis2transport>
> -DxmlParserLibraryName=<axis xml parser wrapper to use, e.g. axis_xerces>
> -DtestHost=<name of server hosting web services> -DtestPort=<server port>
> These can be put into a properties file and loaded with ant -propertyfile
> <path to property file> -f test.xml
> Or the properties can be added to the end of the
> build.<platform>.properties
> Unfortunately there is a bit of a clash with the build process so these
> properties should not be defined for the build, but only for test. I am
> working on re-structuring the test.xml to be cleaner. The re-structuring
> of
> the ant build process has made some of the old properties are no longer
> defined which is why so many have to be specified for test.
> Some of the tests have been written to call services which are not yet in
> the Axis C++ project so some will fail.
> You can create a file in the tests/auto_build/testcases directory called
> test.list which will contain the list of wsdls to run tests for, e.g. if
> the file contained
> tests/auto_build/testcases/wsdls/CalculatorDoc.wsdl
> tests/auto_build/testcases/wsdls/ExceptionTestDoc.wsdl
> tests/auto_build/testcases/wsdls/FaultMappingDoc.wsdl
> tests/auto_build/testcases/wsdls/MathOpsDoc.wsdl
> only those 4 tests would be run.
> You can also create a file called test.endpoints which specified the
> endpoint to call, but without any server or port information as this is
> get
> from the testHost and testPort properties. e.g. if the testHost was set
> testserver and the testPort was set to 9080 and the test.endpoints
> contained
> CalculatorDocEP = Calculator/services/Calculator
> ExceptionTestDocEP = ExceptionTest/services/MathOps
> FaultMappingDocEP = FaultMapping/services/MathOps
> MathOpsDocEP = MathOps/services/MathOps

According to this scheme clients can be tested only against one server one
time, because we can specify only one testserver and testPort, right?
So if we have a file containing









clients can send to different servers.  This file is an auto-generated one.
You need to just change the server and port


> then the CalculatorDoc test would be passed a URL endpoint of
> http://testserver:9080/Calculator/services/Calculator, which calls a Java
> version of the service hosted on IBM WebSphere.
> Hope this is enough for now. All I can say is that it will improve
> and there will be documentation to go along with it.
> Regards
> Andrew Perry
> Clients for Web Service Stack
> Mail Point 127
> IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
> Tel. Internal 249828  External + 44 (0)1962 819828
> Fax. + 44(0)1962 818080
>              Valentin
>              Kuznetsov
>              <
>              m>                        Apache AXIS C Developers List
>                                        <>
>              20/10/2004 18:49
>              Please respond to         Re: Solaris and 1.3 release
>               "Apache AXIS C
>              Developers List"
> Hi,
> just want to let you know that I'm finally built
> axis-c 1.3 on Solaris using ant build system.
> Few comments though:
> 1) I modified src/engine/HandlerChain.h (see thread
> for this Email)
> 2) I used java 1.4 and axis 1.2 (as Adrian suggested)
> 3) I remove documentation from "production" tag in
> build.xml since on Solaris we don't have doxygen. I
> think we need to make "documentation" optional anyway.
> I don't want install ANOTHER package which is not
> necessary for building and using axis.
> I still waiting for people "approval" on
> HandlerChain.h
> problem to commit changes to CVS.
> Next step would be get frozen 1.3, build it and test
> it on Solaris.
> Adrian, could you please let me know how I can perform
> standard tests using ant/build.xml?
> Valentin.
> --- Adrian Dick <> wrote:
>> Valentine,
>> Looking at your classpath, it seems you're using
>> Axis Java 1.1.
>> > /cdat/tem/vk/axis/axis-1_1/lib/axis.jar:
>> >
> /cdat/tem/vk/axis/axis-1_1/lib/commons-discovery.jar:
>> >
>> /cdat/tem/vk/axis/axis-1_1/lib/commons-logging.jar:
>> > /cdat/tem/vk/axis/axis-1_1/lib/jaxrpc.jar:
>> > /cdat/tem/vk/axis/axis-1_1/lib/log4j-1.2.8.jar:
>> > /cdat/tem/vk/axis/axis-1_1/lib/saaj.jar:
>> > /cdat/tem/vk/axis/axis-1_1/lib/wsdl4j.jar:
>> Having just downgraded the version on my machine to
>> 1.1, I see the same
>> compile errors as in your log.
>> The WSDL2Ws tool is now dependent on Axis Java 1.2.
>> Regards,
>> Adrian
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.

View raw message