Log of /webservices/axis/trunk/java/buildTest.xml
Parent Directory
|
Revision Log
Revision
257238 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Fri Dec 26 15:18:49 2003 UTC
(5 years, 11 months ago)
by
gdaniels
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 15278 byte(s)
Diff to
previous 257230
(
colored)
The first item here seemed like a very simple change
to make - however once I did it all-tests wouldn't
run, and I gradually teased out all the other stuff
as a part of this process. The "executive summary"
is that we weren't, and still aren't, handling
typing and array serialization very well in some
cases, although it's much better now.
* Respect the setting of the "send_type_attr" property
when serializing. We used to always turn off xsi
types when in non-encoded mode. Now instead we
merely default to no type attributes when literal,
allowing the property setting, if any, to
override.
* Make sure property parent chains actually work. On
the client, doing a getProperty() on a MessageContext
gets you MC -> Service -> Call -> Engine properties.
On the server, it's MC -> Service -> Engine.
* SerializationContext now writes xsi:type onto an
element if the "writeXmlType" variable is filled in
when startElement() gets called. It used to just
throw the type value into the active Attributes
object, which caused problems when that Attributes
object was shared (which happened when serializing
maxOccurs-style collections with the ArraySerializer;
we'd end up with an attribute value "foo:bar" which
would get written on each element, but the namespace
declaration for "foo" would only be on the first
one, producing invalid XML (!))
* Rationalize property handling in SerializationContext
utilizing the property parent hierarchy.
* TypeMapping.getXmlType() now knows whether or not it
is being used in a SOAP-encoded context, and if not,
never returns SOAP_ARRAY for random arrays.
* ArraySerializerFactory gets a constructor which tells
the serializer which java type and XML type it is
being configured for. This allows this information
to pass through to the ArraySerializer itself.
* Remove the part of ArraySerializer that checks the
name of the serialized element against a parameter
in the current operation - we're not always
serializing a parameter, so this is the wrong place
for this.
* Respect the default config for sendXsiTypes when
serializing arrays, and pass type info down to
SerializationContext.serialize() for members.
* Add an accessor to get the current SOAP_ARRAY type
from a SOAPConstants.
* Do a better job convert()ing to OctetStream.
* de-main()-ify a couple of junit tests (we used to
like putting main()s on there, but since you can
easily run the tests with junit.textui.TestRunner
anyway, removing it makes test debugging inside
IDEs much nicer)
* Allow Exceptions thrown by various tests to bubble
up to the surface so we can see what actually went
wrong.
* Exclude wsdl/adaptive test from the build and reopen
bug #18056. We need to figure out a better way of
dealing with this. I set up a framework for it by
adding an "arrayTypeQNames" Set to SymbolTable, and
checking against the set when figuring out if
something is a SOAP array in SchemaUtils - didn't
quite get it working though.
Revision
255522 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Thu Oct 17 20:41:10 2002 UTC
(7 years, 1 month ago)
by
tomj
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 14504 byte(s)
Diff to
previous 255361
(
colored)
Enhancement 9393:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9393
Add the --extraClasses (-e) option to Java2WSDL.
Add the setExtraClasses(String) and setExtraClasses(Class[])
APIs to the Emitter class.
Update the reference documentation to include the --use
and --extraClasses switches.
Reworked the Style.java enumeration class which is refered
to in the docs to a) have the comments be in the Javadoc for
the class and b) escape the angle-brackets so thing show up
in the Javadoc correctly.
Add the extraClasses option to the Java2WSDL ant task.
Add a test case to test the new option (test/wsdl/extra)
In the process, clean up the functional test targets so
they do not start the TCP server, which is only needed for
the test.function tests. This required some surgery on the
RunAntFunctionTests.java ant thingy. The attributes were
changed from startTarget1/2 to tcpServerTarget and httpServerTarget.
stopTarget was changed to httpStopTarget.
I fixed up the test/function/build.xml file to not deploy
the whole world.
The test/wsdl/filegen test no longer needs to start
up ANY servers, as all its is doing is testing for file
existence.
NOTE: Any ant guru's out there, if we could prevent the AdminClient from
getting run when there are no deploy/undeploy files, that would be great.
Revision
255237 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Thu Sep 19 15:58:02 2002 UTC
(7 years, 2 months ago)
by
dims
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 13891 byte(s)
Diff to
previous 255221
(
colored)
Fixes to build system:
- adding inheritAll and inheritRefs flag to all "<ant" calls and set them to false by default.
- flags can be controlled from properties.xml
- sanitized "<ant" calls such that they have a dir attribute and the ant file attribute has the name of the build file relative to that dir
- cleanup interop a bit
- force a delete of samples/userguide/example6 classes to prevent gump failure.
Revision
255221 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Wed Sep 18 14:39:08 2002 UTC
(7 years, 2 months ago)
by
seibert
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 14071 byte(s)
Diff to
previous 255216
(
colored)
This separates out the junit and functional tests into two targets
so that when you run one, it only does what is needed.
It also makes the comment on "my-forking-ant" a little more friendly
This also fixes the problem that running "ant all" doesn't run junit tests
Revision
254773 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Fri Aug 9 14:57:10 2002 UTC
(7 years, 3 months ago)
by
seibert
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 14199 byte(s)
Diff to
previous 254769
(
colored)
I have added the architecture for my batchTest grouping (the first logical
expansion of the component framework). It works by:
1) Gathering all buildComponent.xml file names
2) Starting the server
3) calling the implicit junit-component target of each buildComponent.xml file
4) Stopping the server
This very closely mimics the running of the current functional-tests target
Revision
254628 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Tue Jul 23 16:17:12 2002 UTC
(7 years, 4 months ago)
by
scheu
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 19813 byte(s)
Diff to
previous 254619
(
colored)
Following changes made:
* Fix for Bugzilla 11084, Stub variable collisions.
The local variables are prepended with _.
Removed qname variables that were generated for each parameter name.
* Common code in the stub/skeleton/deploy writers for getting the
qname type is combined in the new Utils.getXSIType(TypeEntry)
method. This change eliminates a lot of code and potential flaws.
* Various minor changes to make the code more readable.
PR:
Obtained from:
Submitted by:
Reviewed by:
Revision
254619 -
(
view)
(
annotate)
-
[select for diffs]
Modified
Tue Jul 23 01:14:23 2002 UTC
(7 years, 4 months ago)
by
stevel
Original Path:
webservices/axis1/trunk/java/buildTest.xml
File length: 19812 byte(s)
Diff to
previous 254617
(
colored)
removed unneeded duplication of <property env>l titied up another test then cleaned up some target defns w/ descriptions and word wrap. probability of anythign breaking, pretty much minimal, only the debug condition underwent any effective change as now yes and true are also valid, and case is not important either.
...dunno what having env.debug does anyway. if you want debugging, set it in your own properites or to true on the command line
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
enter a numeric revision.