- 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, the spring-cache XSD allowed a 'key-generator'
attribute, but it was not actually parsed by AnnotationDrivenCacheBDP.
This commit adds the parsing logic as originally intended and the test
to prove it.
Issue: SPR-8939
Prior to this change, the caching reference docs referred to
'root.params', whereas the actual naming should be 'root.args'. This
naming was also reflected in the "#p" syntax for specifying method args.
This change updates the documentation to refer to 'root.args' properly
and also adds "#a" syntax for specifying method arguments more
intuitively. Note that "#p" syntax remains in place as an alias for
backward compatibility.
Issue: SPR-8938
Reconciled all 3.1.1 dev against 3.1.x and master (3.2.x) branches.
From this point forward, all 3.1.1 dev should happen directly against
3.1.x, and we will periodically merge those changes into master.
Note that when these merges take place, there will be a conflict
among any files containing version numbers, such as build.properties
and pom files. Use `git rerere` to record the conflict resolution
strategy for future merges, avoiding redundant work.
$ git config --global rerere.enabled 1
$ git checkout master
$ git merge 3.1.x # conflicts
$ git checkout master # take master version of all affected files
$ git commit # conflict resolution strategy is remembered
See http://progit.org/2010/03/08/rerere.html
Conflicts:
build.properties
org.springframework.aop/pom.xml
org.springframework.asm/pom.xml
org.springframework.aspects/pom.xml
org.springframework.beans/pom.xml
org.springframework.context.support/pom.xml
org.springframework.context/pom.xml
org.springframework.core/pom.xml
org.springframework.expression/pom.xml
org.springframework.instrument.tomcat/pom.xml
org.springframework.instrument/pom.xml
org.springframework.integration-tests/pom.xml
org.springframework.jdbc/pom.xml
org.springframework.jms/pom.xml
org.springframework.orm/pom.xml
org.springframework.oxm/pom.xml
org.springframework.spring-library/pom.xml
org.springframework.spring-parent/pom.xml
org.springframework.test/pom.xml
org.springframework.transaction/pom.xml
org.springframework.web.portlet/pom.xml
org.springframework.web.servlet/pom.xml
org.springframework.web.struts/pom.xml
org.springframework.web/pom.xml
Rossen Stoyanchev
Arjen Poutsma
Chris Beams
Costin Leau
Juergen Hoeller