The initial solution kept these three in full sync at all times:
contentType field, characterEncoding field, 'Content-Type' header.
That is correct behavior, however it breaks existing tests that rely
on contentType and characterEncoding being equal to exactly what
they were set to.
For example, consider:
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
Ideally both contentType and the 'Content-Type' header would now be
"text/plain;charset=UTF-8". However, existing tests would expect
that contentType is equal to "text/plain".
To avoid breaking existing tests, contentType and characterEncoding
will continue to be equal to exactly what they were set to while
the 'Content-Type' header will always include both the content
type and the charset.
The only exception to this rule is when a 'Content-Type' header
is set explicitly, the contentType and characterEncoding fields will
be updated accordingly, possibly overriding the existing values.
The Content-Type header and the contentType field in HttpServletRequest/Response
are now always in sync. When a header is added the contentType field is updated
as well and vice versa.
Similarly when the Content-Type header or the contentType field includes a charset
field, the character encoding is updated and vice versa.
- Removed generatesDefaults() and supports() from the SmartContextLoader SPI and modified the DelegatingSmartContextLoader algorithm accordingly.
- DelegatingSmartContextLoader no longer operates on a list of candidate loaders but rather on explicit instances of GenericXmlContextLoader and AnnotationConfigContextLoader.
- Updated Javadoc regarding DelegatingSmartContextLoader as the new default loader.
- Updated and polished Javadoc regarding changes in 3.1.
- Now enforcing @ContextConfiguration's restriction on declaring locations or classes but not both.
- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration
- TextContext now works with MergedContextConfiguration instead of locations and loader
- TextContext now builds context caching key from MergedContextConfiguration
- Test context caching is now based on locations, classes, active profiles, and context loader
- TextContext now delegates to SmartContextLoader or ContextLoader as appropriate
- AbstractContextLoader now implements SmartContextLoader
- AbstractGenericContextLoader now sets active profiles in the GenericApplicationContext
- Introduced integration tests for profile support in the TCF for both XML and annotation config
