Previously flash attributes were automatically merged into the
model of annotated controllers only. This change extends the same
benefit to ParameterizableView- and UrlFilenameViewController,
both of which merely select a view without user controller logic
and (the views) would otherwise not have access to the flash
attributes.
When checking for an exact match of Accept header media types
additional parameters such as quality need to be excluded.
For example "*/*" matches "*/*;q=0.9".
- Eliminate trailing whitespace
- Update long method signatures to follow framework whitespace
conventions
Based on the following search,
$ git grep -A3 '^.public .* .*([^\{;]*$' */src/main
the strong convention throughout the framework when dealing with
methods having long signatures (i.e. many parameters) is to break
immediately after the opening paren, indent two tabs deeper and break
lines around 90 characters as necessary. Such signatures should also
be followed by a newline after the opening curly brace to break
things up visually.
The files edited in this commit had a particularly different style of
intenting arguments to align with each other vertically, but the
alignment only worked if one's tabstop is set at four spaces.
When viewed at a different tabstop value, the effect is is jarring,
both in that it is misaligned and significantly different from most
of the framework. The convention described above reads well at any
tabstop value.
Before this change, flash attributes could only be added if via
RedirectAttributes.addFlashAttribute(..) if the method returned
a view name or a View instance. With this change, the above is
supported with a ModelAndView return value as well.
Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.
This change normalizes these files to LF for consistency going forward.
Command used:
$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix
Issue: SPR-5608
Prior to this fix, ContextLoader(Listener)'s would overwrite any
value set directly against a WebApplicationContext's #setConfigLocation
method. This is a likely scenario when using Spring 3.1's new
WebApplicationInitializer support.
Now a check is performed to ensure that the ContextLoader init-param
value is non-null before doing the overwriting.
Added tests to ensure that all expected precedence, overwriting and
defaulting of context config locations works as expected.
Issue: SPR-8510
This method allows a view to access the combined context path and
servlet mapping path for prefixing URLs without having to specify
the literal part of a servlet mapping such as "/main/*")
explicitly everywhere. For example:
${requestContext.pathToServlet}/css/main.css
Currently the combine method consolidates "/*" and "/hotel"
into "/hotel". However if the first pattern contains URI template
variables, the consolidation seems wrong. The fix is to prevent
the consolidation if the first pattern contains "{".
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
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.
Since dynamic attributes were allowed in Spring 3, it raised the
possibility to specify a type attribute on a number of the form tags.
Where it makes sense (see below) that attribute is now rejected
and reversely where it makes sense it is accepted.
InputTag allows types other than "text" but rejects type="radio" or
type="checkbox" since there is a good reason for those to be used
only in conjunction with the appropriate form library tags.
Other HTML input tags such as PasswordTag, HiddenInputTag,
Checkbox(es)Tag and RadioBox(es)Tag check the dynamic attributes
and reject them if they contain a type attribute since.
Make it possible to hook in custom ServletRequestDataBinderFactory
by overriding RequestMappingHandlerAdapter.
Create ExtendedServletRequestDataBinder to add URI template vars
to the binding values taking advantage of a new extension hook in
ServletRequestDataBinder to provide additional values to bind.
RequestCondition types keep individual expression types (e.g. the
discrete header or param expressions) package private. Although the
implementation of these types should remain private, there is no
reason not to provide access to the underlying expression data --
e.g. for creating a REST endpoint documentation tool, or if you
want to know which of the "consumes"/"produces" media types
are negated.
This change ensures that all RequestCondition types have a public
getter that makes available the basic expression data.
1. Consider single-purpose return value types like HttpEntity, Model,
View, and ModelAndView ahead of annotations like @ResponseBody and
@ModelAttribute. And reversely consider multi-purpose return value
types like Map, String, and void only after annotations like
@RB and @MA.
2. Order custom argument resolvers and return value handlers after the
built-in ones also clarifying the fact they cannot be used to override
the built-in ones in Javadoc throughout.
3. Provide hooks in RequestMappingHandlerAdapter that subclasses can use
to programmatically modify the list of argument resolvers and return
value handlers, also adding new getters so subclasses can get access
to what they need for the override.
4. Make SessionStatus available through ModelAndViewContainer and
provide an argument resolver for it.
5. Init test and javadoc improvements.
When set to 'true' the flag makes RedirectAttributes the only way to add
attributes for a redirect thus ignoring the content of the default model
even if RedirectAttributes is not in the list of controller method args.
Separate client from server errors as much as possible in this order:
- raise MultipartException when resolving a multipart arg and the
request is not a multipart request (400)
- raise IllegalArgumentException when the arg type is MultipartFile
but the request is not of type MultipartHttpServletRequest (500)
- raise MissingServletRequestPartException when a MultipartResolver
is in use but the part is not found (400)
- detect presence of Servlet 3.0 before using standard multipart
parsing to find a request part or raise
IllegalArgumentException (500)
Unfortunately it is not always possible to separate client from
server errors mainly because the Servlet 3.0 API does not
distinguish between the case of 0 request parts vs multipart
processing not being configured.
