The spring-aspects Maven pom had an incorrect compile-scoped dependence
on spring-test. In fact, spring-aspects only uses spring-test in its
unit tests. The pom has been updated accordingly, meaning that use
of spring-aspects in Maven-based applications will no longer require
spring-test on the classpath at runtime.
ivy.xml metadata did not need updating, as it was already correct.
This change is only necessary on the 3.1.x line; in 3.2.x (master) Maven
poms are generated automatically from Gradle dependency metadata, which
is also already correct.
Issue: SPR-9048
A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.
With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
Prior to this commit, @Configuration classes included via @Import (or
via automatic registration of nested configuration classes) would
always be registered with a generated bean name, regardless of whether
the user had specified a 'value' indicating a customized bean name, e.g.
@Configuration("myConfig")
public class AppConfig { ... }
Now this bean name is propagated as intended in all cases, meaning that
in the example above, the resulting bean definition of type AppConfig
will be named "myConfig" regardless how it was registered with the
container -- directly against the application context, via component
scanning, via @Import, or via automatic registration of nested
configuration classes.
Issue: SPR-9023
A number of users reported issues with comparing method identity vs
equivalence when discovering JavaBeans property methods in
ExtendedBeanInfo.
This commit updates the implementation to consistently use '.equals()'
instead of '=='.
Issue: SPR-8079, SPR-8347
This change introduces a protected ReflectiveMethodResolver#getMethods,
allowing subclasses to specify additional static methods not
declared directly on the type being evaluated. These methods then become
candidates for filtering by any registered MethodFilters and ultimately
become available within for use within SpEL expressions.
Issue: SPR-9038
The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.
This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).
When switching back to 3.1.x from master, ignore renamed directories,
Gradle 'build' dirs, generated IDE metadata, etc.
You may wish to clean these files with
$ git clean -dfx
Or do a dry-run beforehand with the '-n' flag:
$ git clean -dfxn
A direct path match with incorrect HTTP request method was causing another
request mapping with a pattern and a correct HTTP method to be ignored.
The bug affects the new @MVC support classes
(i.e. RequestMappingHandlerMapping).
It should be possible to progress from extending
WebMvcConfigurerAdapter (w/ @EnableWebMvc) to extending
WebMvcConfigurationSupport directly, to extending
DelegatingWebMvcConfigurationSupport. This change
makes that possible.
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.
Chris Beams
Rossen Stoyanchev
Andy Clement
Arjen Poutsma
Arjen Poutsma
Chris Beams
Juergen Hoeller
Costin Leau