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.
Previously, #containsBean Javadoc advertised that a true return value
indicates that a call to #getBean for the same name would succeed.
This is actually not the case, and has never been. The semantics
of #containsBean have always been to indicate whether a bean definition
with the given name is definied or a singleton instance with the given
name has been registered.
The Javadoc now reflects this accurately.
Issue: SPR-8690
Cite original inspiriation by Domain-Driven Design, but make clear the
flexible and general-purpose nature of Spring's stereotype annotations
such as @Repository and @Service.
Also update @Repository Javadoc with more explicit instructions about
switching on exception translation through use of
PersistenceExceptionTranslationPostProcessor, and update PETPP Javadoc
for style as well as concrete examples of 'resource factories' that
implement the PersistenceExceptionTranslator interface
Issue: SPR-8691
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.
Commit http://bit.ly/nXumTs ensured that component methods and fields
marked with 'common annotations' such as @Resource, @PostConstruct and
@PreDestroy are invoked/assigned once and only once, even if multiple
instances of the CommonAnnotationBeanPostProcessor are processing the
same bean factory.
The implementation works against the InjectionMetadata API, adding and
removing these members from sets that track whether they are already
'externally managed', i.e. that another CABPP has already handled them,
thus avoiding redundant processing.
Prior to this change, the #remove operations against these sets were
not synchronized. In a single-threaded context this is fine thanks to
logic in AbstractAutowireCapableBeanFactory#doCreateBean that checks to
see whether a given bean definition has already been post processed.
However, as reported by SPR-8598, certain cases involving multiple
threads and annotated prototype-scoped beans can cause concurrent
modification exceptions during the #remove operation (ostensibly because
another thread is attempting to do the same removal at the same time,
though this has yet to be reproduced in isolation).
Now the sets originally introduced by the commit above are decorated
with Collections#synchronizedSet and any iterations over those sets
are synchronized properly. This change should have low performance
impact as such processing happens at container startup time (save for
non-singleton lookups at runtime), and there should be little
contention in any case.
Issue: SPR-8598
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.
Prior to this change, spring-orm/template.mf was exclusive of javax.jdo
3.0.0. Now, after local testing against the newly-released jdo-api 3.0
jar, the template has been updated to allow for use in OSGi containers.
Note that actually updating build dependency descriptors to JDO 3.0 such
that the framework is continually tested against this version is covered
by a separate issue (SPR-8668).
Issue: SPR-8667, SPR-8655
Rossen Stoyanchev
Sam Brannen
Arjen Poutsma
Chris Beams
Keith Donald
Costin Leau