Before this change client-side tests prepared a response using overloaded methods withResponse(..) accepting arguments for the response status, headers, and body. .andRespond(withResponse("foo", headers, HttpStatus.OK, "")) This change deprecates those methods and introduces a builder-style approach for providing the same information supporting common use cases. A few examples: .andRespond(withSuccess("foo", MediaType.TEXT_PLAIN)) .andRespond(withCreatedEntity(new URI("/foo"))) .andRespond(withNoContent()) The withRespones(..) methods have been deprecated.
This change removed the current settings for deploying artifacts to S3 and replaced the repository with the SpringSource Artifactory repository. More details at the SpringSource Repository FAQ: https://github.com/SpringSource/spring-framework/wiki/SpringSource-repository-FAQ
The DefaultRequestBuilder no longer allows setting the pathInfo. Instead it is derived from the request URI minus the context and servlet paths. If the context and servlet paths are not specified, the pathInfo should be the same as the request URI.
…s an alternative to specifying header values individually. Added the ability to verify headers in a ReqestMatcher using a HttpHeaders object. This adds some consistency to the process of providing and verifying headers. Added a requestToContains matcher to RequestMatchers. This is useful when you only want to verify that the path part of a URI is correct, and ignore the host.
The main goal of the refactoring is to use the actual DispatcherServlet instead of the custom MockDispatcher used till now. This was done by introducing a DispatcherServlet sub-class, which creates an MvcResult instance at the start of a request, stores it in a request attribute, and populates it as the request gets executed. The only way to initialize the DispatcherServlet is to provide it with a WebApplicationContext containing Spring MVC infrastructure components and controllers. As a result of this, the MvcSetup contract, previously prepared by MockMvcBuilders and used in the MockDispatcher, can no longer be used. Removing the MvcSetup simplifies WebApplicationContext-based MockMvcBuilders. However, the StandaloneMockMvcBuilder needed to be refactored. After the refactoring it "borrows" infrastructure set up by the MVC Java conifg WebMvcConfigurationSupport and uses it to populate a "stub" WebApplicationContext that accepts registrations of singletons. Hence the StandaloneMockMvcBuilder can continue to exist and to provide an option for manual, unit test style testing where controllers can be instantiated and configured manually with dependencies (e.g. mock objects). Fortunately there are no backwards compatibility issues in this change that is unless tests did any advanced extensions of MockMvcBuilders in which case some adjustments may be necessary.