axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sanjaya singharage" <sanja...@opensource.lk>
Subject Re: backing up customised ant configuration
Date Wed, 30 Mar 2005 04:38:12 GMT
Please see my comments below....

----- Original Message -----
From: "Adrian Dick" <adrian.dick@uk.ibm.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Sent: Tuesday, March 29, 2005 7:26 PM
Subject: Re: backing up customised ant configuration


> Hi,
>
> This all sounds good.
>
> I have few comments below on things that can be done for client-side
> testing which can help avoid this problem.  I haven't (yet) tried the
> server-side testing, so am uncertain if it can do the same.
>
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
>
>
> "sanjaya singharage" <sanjayas@opensource.lk> wrote on 29/03/2005
13:38:19:
>
> > A small ant script backupconf.xml is now created so that testers can
> back-up
> > and restore locally modified ant configurations. The targets are backup
> and
> > restore.
> >
> > What is backed up is...
> > 1. the server.wsdd.PLATFORM for the ant service framework
> Are these not generated "on-the-fly" by the ant framework? As is done when
> testing client-side handlers.
>

No. because the server.wsdd requires the allowed methods to be declared
within a parameter element and I could not find a way to make them visible
to the ant scripts since it can only be known through the wsdl/wsdl2ws. I
tried to use the generated deploy.wsdd as a property file to obtain the
allowed method information but was unable because there are several elements
with the same name "parameter", but I think there might be a way to do it.
and so for the service framework we need to keep a static server.wsdd file
at least for the moment, which needs to be update whenever new service is
added.

> > 2. build.PLATFORM.properties
> An alternative is to use -Ddir.properties=<my dir with my version of
> build.PLATFORM.properties>
>
> > 3. The client side test XMLs
> You can specify -Dtest.list=<location my test.list file> which is simply a
> test file with an entry for each desired <test>.xml to be used, instead of
> having to delete those you're currently not interested in.
>
can this list specify a set of xmls in a separate location other than the
original location in cvs? My idea in backing these up were to allow a tester
to have his own endpoints rather than the default ones.

> > 4. The services XMLs
> Perhaps a similar system could be used here as in step 3.
>
>
>



Mime
View raw message