* Make it possible to run the build with different dependencies and different version of JDK
* Fix JUnit to make it forward compatible
* Fix other things that are deprecated in Spring 4.3 and removed in Spring 5
This commit introduces a ClientInterceptorAdapter with a default implementation
of the methods and providing a protected Log instance for subclasses. This convenience
class allows for pre-/post only ClientInterceptor instances without having to
add empty methods to it.
The getName() method in JaxbStreamingPayload doesn't report the actual
namespace prefix that is later generated by the writeTo method. With
Axiom 1.2.13 that didn't cause problems, but 1.2.14 is less lenient,
causing an error as described in AXIOM-463.
This change:
* Updates the StreamingPayload documentation to specify that the
namespace prefix in the QName returned by getName() has no significance
(which is effectively how things are currently).
* Updates AxiomSoapBody so that it Axiom is aware that the namespace
prefix of the created OMSourcedElement is unknown.
* Modifies the unit test for setStreamingPayload so that it uses a
StreamingPayload with a prefix mismatch.
Correction for multiple keys with different values in HTTP Response.
Before, in response of mimeheader:
- cookie: value2
- cookie: value2
Now :
- cookie: value1
- cookie: value2
Issue: SWS-924
More recent versions of HTTP components normalise an HTTPHost when it’s
used to create an HTTPRoute. As part of this normalization the host’s
port is set to the default port for the host’s scheme, e.g. an https
scheme will result in a port of 443 and an http scheme will result in
a port of 80
This commit updates the tests so that they will accept the behaviour
of HTTP Components 4.3.x (the port is -1) and HTTP Components 4.5.x
(the port is 80 for http and 443 for https). Compatibility with HTTP
Components 4.5.x allows Spring Web Services’ tests to pass when
they’re run as part of the Spring IO Platform 2.0 release process
which uses a more recent version of HTTP components than the default
Spring Web Services build.
XML schema validation accepting multiple schemas currently uses arrays
of Resource objects. They would be a bit easier and more succinct to
use if the setters were switched to varargs. Such a change would be
backwards compatible.
This change includes:
* change AbstractValidatingInterceptor#setSchemas to use varargs
* change the CommonsXsdSchemaCollection constructor to use varargs
* change CommonsXsdSchemaCollection.setXsds to use varargs
* update the tests to use varargs
Issue: SWS-921
https://jira.spring.io/browse/SWS-921
The project contains various easy to fix compiler warnings like unused
imports, raw types and no longer needed @SuppressWarnings("unchecked").
This change removes:
* unused imports
* raw types
* no longer needed @SuppressWarnings("unchecked")
Issue: SWS-918
https://jira.spring.io/browse/SWS-918
* Created an interface to mark where request and response headers may be accessed
* Updated related classes to use the interface, and in turn, update method visibility
* There are sets of classes aimed at requests and another at repsonses. Have interfaces to serve both, for symmetry.
When configuring max connections for a secured route, the HttpRoute is actually not secured. This causes an improper lookup.
This change updates the test case to ensure several things are verified including the fix provided.
The current code basically assumes that if the payload is a SAXSource,
then it must be backed by a SAX parser. It then passes only the
InputSource to the unmarshaller and ignores the XMLReader. Presumably
this is an optimization because the unmarshaller will likely parse the
XML message in a more efficient way.
This approach causes a problem if the SAXSource is not backed by a
parser but generates the sequence of SAX events using a custom
XMLReader.
SOAP v1.2 specifies that for SOAP Fault's with Code of "env:Sender" the
HTTP response status code should be 400 (rather than 500 for all other
faults). This commit changes both client and server-side to reflect
this.
Issue: SWS-868
All WS-Addressing EndpointsMappings now support endpoint interceptors
registered via a <sws:interceptors/> block (i.e.
SmartEndpointInteceptors).
Issue: SWS-874
