You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Andrew Perry2 <PE...@uk.ibm.com> on 2004/10/21 18:09:00 UTC
Re: Solaris and 1.3 release (Running tests)
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 to
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
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 shortly
and there will be documentation to go along with it.
Regards
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
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
<vkuznet@yahoo.co To
m> Apache AXIS C Developers List
<ax...@ws.apache.org>
20/10/2004 18:49 cc
Subject
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 <ad...@uk.ibm.com> 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.
http://promotions.yahoo.com/new_mail
Re: Solaris and 1.3 release (Running tests)
Posted by da...@opensource.lk.
Hi Andrew,
>
>
>
>
> 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.
This is very good feature. Otherwise we cannot verify certain tests.
>
> 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.
True, this is a problem
>
> 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.
Yes, we need to do this.
> 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.
>
> Regards
>
> Andrew Perry
> Clients for Web Service Stack
> perryan@uk.ibm.com
> 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
>
>
>
> damitha@opensourc
> e.lk
> To
> 22/10/2004 07:56 "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> cc
> 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
> to
>> 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
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
>
> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
>
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
>
> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
>
> clients can send to different servers. This file is an auto-generated
> one.
> You need to just change the server and port
>
> thanks
> damitha
>
>
>
>>
>> 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
> shortly
>> and there will be documentation to go along with it.
>>
>> Regards
>>
>> Andrew Perry
>> Clients for Web Service Stack
>> perryan@uk.ibm.com
>> 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
>> <vkuznet@yahoo.co
> To
>> m> Apache AXIS C Developers List
>> <ax...@ws.apache.org>
>> 20/10/2004 18:49
> cc
>>
>>
> Subject
>> 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 <ad...@uk.ibm.com> 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.
>> http://promotions.yahoo.com/new_mail
>>
>>
>>
>>
>
>
>
>
>
Re: Solaris and 1.3 release (Running tests)
Posted by da...@opensource.lk.
> Few thoughts on hot names an ports (have a look at the end of the email)
>
> --- damitha@opensource.lk wrote:
>
>> 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 to
>> > 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
>>
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
>>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
>> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
>>
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
>> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
>> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
>>
>> clients can send to different servers. This file is an auto-generated
>> one.
>> You need to just change the server and port
>
> It is a good idea to be able to have the option of connecting to different
> servers and different
> ports.
> However, can we make the host and port parts in above configuration
> optional, so that if present,
> the specified values would be picked, if not default (or globle) value
> would be used.
>
> This makes life easy in case one is using the same server/port for all
> tests - which is the more
> common case.
Yes this feature is currently availble in the script based version. There,
as I said test.config is generated in which each service is listed with
default host and port as given in apache_ports.config. Once it generated
for the default host and port we can change the host and port for selected
services and run the testcases for them. What I mean is, it is good to
have this in ant version.
thanks
damitha
>
> Samisa...
>
>>
>> thanks
>> damitha
>>
>>
>>
>> >
>> > 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
>> shortly
>> > and there will be documentation to go along with it.
>> >
>> > Regards
>> >
>> > Andrew Perry
>> > Clients for Web Service Stack
>> > perryan@uk.ibm.com
>> > 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
>> > <vkuznet@yahoo.co
>> To
>> > m> Apache AXIS C Developers List
>> > <ax...@ws.apache.org>
>> > 20/10/2004 18:49
>> cc
>> >
>> > Subject
>> > 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 <ad...@uk.ibm.com> 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.
>> > http://promotions.yahoo.com/new_mail
>> >
>> >
>> >
>> >
>>
>>
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
>
Re: Solaris and 1.3 release (Running tests)
Posted by Andrew Perry2 <PE...@uk.ibm.com>.
I've changed test.xml so if there is no entry in the test.endpoints file it
will not pass any arguments to the client and the client will use whatever
default it has in it's code or the WSDL default depending upon how the stub
constructor get called. If the value in the test.endpoints is
UseSpecifiedServerPort, then -p ${testPort} -s ${testHost} will be passed
to the client.
This is how it should have originally been. I'm looking into what it would
take to re-write the framework.
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
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
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
22/10/2004 09:17 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Solaris and 1.3 release
Developers List" (Running tests)
Few thoughts on hot names an ports (have a look at the end of the email)
--- damitha@opensource.lk wrote:
> 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
to
> > 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
>
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
>
/home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
>
> clients can send to different servers. This file is an auto-generated
one.
> You need to just change the server and port
It is a good idea to be able to have the option of connecting to different
servers and different
ports.
However, can we make the host and port parts in above configuration
optional, so that if present,
the specified values would be picked, if not default (or globle) value
would be used.
This makes life easy in case one is using the same server/port for all
tests - which is the more
common case.
Samisa...
>
> thanks
> damitha
>
>
>
> >
> > 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
shortly
> > and there will be documentation to go along with it.
> >
> > Regards
> >
> > Andrew Perry
> > Clients for Web Service Stack
> > perryan@uk.ibm.com
> > 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
> > <vkuznet@yahoo.co
To
> > m> Apache AXIS C Developers List
> > <ax...@ws.apache.org>
> > 20/10/2004 18:49
cc
> >
> >
Subject
> > 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 <ad...@uk.ibm.com> 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.
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
> >
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Solaris and 1.3 release (Running tests)
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Few thoughts on hot names an ports (have a look at the end of the email)
--- damitha@opensource.lk wrote:
> 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 to
> > 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
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
>
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
>
> /home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
> /home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
> /home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
>
> clients can send to different servers. This file is an auto-generated one.
> You need to just change the server and port
It is a good idea to be able to have the option of connecting to different servers and different
ports.
However, can we make the host and port parts in above configuration optional, so that if present,
the specified values would be picked, if not default (or globle) value would be used.
This makes life easy in case one is using the same server/port for all tests - which is the more
common case.
Samisa...
>
> thanks
> damitha
>
>
>
> >
> > 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 shortly
> > and there will be documentation to go along with it.
> >
> > Regards
> >
> > Andrew Perry
> > Clients for Web Service Stack
> > perryan@uk.ibm.com
> > 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
> > <vkuznet@yahoo.co To
> > m> Apache AXIS C Developers List
> > <ax...@ws.apache.org>
> > 20/10/2004 18:49 cc
> >
> > Subject
> > 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 <ad...@uk.ibm.com> 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.
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
> >
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Solaris and 1.3 release (Running tests)
Posted by Andrew Perry2 <PE...@uk.ibm.com>.
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.
Regards
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
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
damitha@opensourc
e.lk
To
22/10/2004 07:56 "Apache AXIS C Developers List"
<ax...@ws.apache.org>
cc
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
to
> 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
/home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
/home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
clients can send to different servers. This file is an auto-generated one.
You need to just change the server and port
thanks
damitha
>
> 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
shortly
> and there will be documentation to go along with it.
>
> Regards
>
> Andrew Perry
> Clients for Web Service Stack
> perryan@uk.ibm.com
> 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
> <vkuznet@yahoo.co
To
> m> Apache AXIS C Developers List
> <ax...@ws.apache.org>
> 20/10/2004 18:49
cc
>
>
Subject
> 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 <ad...@uk.ibm.com> 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.
> http://promotions.yahoo.com/new_mail
>
>
>
>
Re: Solaris and 1.3 release (Running tests)
Posted by da...@opensource.lk.
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 to
> 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
/home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:host=192.168.101.4
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:host=192.168.101.4
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/inquire_v2:host=192.168.101.15
/home/damitha/projects/cvshead/tests/auto_build/SimpleRefDoc:port=80
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeArray:port=9090
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnbounded:port=80
/home/damitha/projects/cvshead/tests/auto_build/SimpleTypeInnerUnboundedInOutput:port=9090
/home/damitha/projects/cvshead/tests/auto_build/inquire_v2:port=9090
clients can send to different servers. This file is an auto-generated one.
You need to just change the server and port
thanks
damitha
>
> 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 shortly
> and there will be documentation to go along with it.
>
> Regards
>
> Andrew Perry
> Clients for Web Service Stack
> perryan@uk.ibm.com
> 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
> <vkuznet@yahoo.co To
> m> Apache AXIS C Developers List
> <ax...@ws.apache.org>
> 20/10/2004 18:49 cc
>
> Subject
> 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 <ad...@uk.ibm.com> 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.
> http://promotions.yahoo.com/new_mail
>
>
>
>