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 some code that can never be executed and can be
removed safely.
This change removes:
* XwsSecurityInterceptor#verifyInboundMessage
* DaoX509AuthoritiesPopulator#logger
Issue: SWS-919
https://jira.spring.io/browse/SWS-919
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
Spring Security 4.0 removed a number of APIs that were deprecated in
3.x. This commit updates SpringSecurityUtils to avoid using those
APIs. This makes it compatible with Spring Security 4.0 while also
retaining compatibility with Spring Security 3.2.x.
Also, upgrade to Spring Security 3.2.7.RELEASE as the latest point release.
Spring IO Platform 2.0 will remove the managed versions .properties
file as support for it has been removed in Spring Boot 1.3.
This commit moves the build onto a new version of the Spring IO Plugin
that uses the Maven bom rather than the properties file.
* 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.
