- 01 3月, 2014 11 次提交
-
-
由 Oliver Gierke 提交于
The breakout box named "Constructor-based or setter-based DI?" in the reference manual currently recommends the use of setter injection. This commit refines this text to align with current best practices and now favors constructor injection over setter injection. Issue: SPR-11459
-
由 Juergen Hoeller 提交于
Also removed outdated Struts references and made use of 'javadocs' term consistent. Issue: SPR-11473
-
由 Juergen Hoeller 提交于
Issue: SPR-11478
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11492
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11488
-
由 Sebastien Deleuze 提交于
Allow Jaxb2RootElementHttpMessageConverter subclasses to customize the {@link Marshaller} and the {@link Unmarshaller} created by the message converter. Issue: SPR-11488
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Brian Clozel 提交于
SpringSource github org name changed to spring-projects.
-
由 Sam Brannen 提交于
-
- 28 2月, 2014 15 次提交
-
-
由 Sam Brannen 提交于
-
由 Rossen Stoyanchev 提交于
AbstractDispatcherServletInitializer now adds a unique suffix to a filter name if it fails to register it. Issue: SPR-11493
-
由 Rossen Stoyanchev 提交于
-
由 Brian Clozel 提交于
Prior to this commit, one had to provide her own RequestMappingHandlerMapping instance (i.e extend WebMvcConfigurationSupport and override the requestMappingHandlerMapping method) in order to customize path matching properties on that bean. Since SPR-10163, XML config users can do that using the <mvc:path-matching/> XML tag. This commit adds the same feature to MVC Java config with a PathMatchConfigurer. Issue: SPR-11486
-
由 Rossen Stoyanchev 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
Issue: SPR-10441
-
由 Juergen Hoeller 提交于
Issue: SPR-11477
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
Before this change CompositeMessageConverter had a ContentTypeResolver field that was in turn set on all contained converters. After this change that field is removed and effectively CompositeMessageConverter is a simple container of other converters. Each converter in turn must have been configured with a ContentTypeResolver. Doing so means it is less likely to have unexpected consequences when configuring converters, the ContentTypeResolver set in the composite converter overriding the one configured in a contained converter. Also commit 676ce6 added default ContentTypeResolver initialization to AbstractMessageConverter, which ensures that converters are still straight forward to configure. Issue: SPR-11462
-
由 Rossen Stoyanchev 提交于
Previously AbstractMessageConverter did not have a ContentTypeResolver configured by default. However the Java config and XML namespace in spring-messaging and spring-websocket always configured one. This change ensures every AbstractMessageConverter is configured with an instance of DefaultContentTypeResolver by default. This makes sense since all the resolver does is make an attempt to find a content type to use for matching. If it can't it returns null and it's up to the converter to decide whether it can convert or not. Issue: SPR-11462
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11484
-
由 Rossen Stoyanchev 提交于
AbstractMessageConverter now supports a strictContentTypeMatching mode in which the content type of a message must be resolved to a (non-null) value that matches one of the configured supported MIME types in order for the converter to be used. Issue: SPR-11463
-
由 Sebastien Deleuze 提交于
After this change DefaultContentTypeResolver supports String-based "contentType" header values in addition to MimeType-based. Issue: SPR-11461
-
- 27 2月, 2014 2 次提交
-
-
由 Brian Clozel 提交于
This commit: * adds a reference to the Spring Code Style wiki page in the main CONTRIBUTING document * updates the link to the Spring team in README * adds a note regarding Intellij IDEA 13 issues
-
由 Sam Brannen 提交于
The previous commit introduced a dependency on Class.getDeclaredAnnotation() which is a Java 8 API. This commit refactors AnnotationUtils.findAnnotation(Class, Class, Set) to use Class.getAnnotation() in conjunction with isAnnotationDeclaredLocally() in order to achieve the same desired behavior. Issue: SPR-11475
-
- 26 2月, 2014 8 次提交
-
-
由 Sam Brannen 提交于
* SPR-11475: Favor 'local' annotations over inherited ones
-
由 Sam Brannen 提交于
Prior to this commit, the implementations of findAnnotation() in AnnotationUtils and getAnnotationAttributes() in AnnotatedElementUtils favored inherited annotations and inherited composed annotations over composed annotations that are declared closer to the starting class passed to these methods. This commit addresses this issue as follows: - Refactored AnnotationUtils to use getDeclaredAnnotation() and getDeclaredAnnotations() instead of getAnnotation() and getAnnotations() where appropriate. - AnnotatedElementUtils.doProcess() supports a traverseClassHierarchy flag to control whether the class hierarchy should be traversed, using getDeclaredAnnotations() instead of getAnnotations() if the flag is true. - Overhauled Javadoc in AnnotatedElementUtils. Issue: SPR-11475
-
由 Juergen Hoeller 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Ant 1.9.2 is packaged with Gradle since release 1.10. Since the Spring Framework build now uses Gradle 1.11, there is no longer a need for the "javac1.7" build compiler work-around for the spring-oxm module.
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
This commit introduces a new isInJavaLangAnnotationPackage(Annotation) method in AnnotationUtils. This method is now used in AnnotationUtils, AnnotatedElementUtils, and MetaAnnotationUtils to ensure that search algorithms do no search for meta-annotations on annotations in the "java.lang.annotation" package. The following are some empirical results from this change: - The number of times that the findAnnotation(Class,Class,Set) method in AnnotationUtils is recursively invoked while executing AnnotationUtilsTests drops from 51 to 29. - The number of times that the process(AnnotatedElement) method in AnnotationUtils.AnnotationCollector is recursively invoked while executing AnnotationUtilsTests.getRepeatableFromMethod() drops from 16 to 2. - The number of times that the doProcess() method in AnnotatedElementUtils is recursively invoked while executing the "getAnnotationAttributes() On MetaCycleAnnotatedClass with missing target meta-annotation" test in AnnotatedElementUtilsTests drops from 23 to 5. - The number of times that the findAnnotationDescriptor(Class,Set,Class) method in MetaAnnotationUtils is recursively invoked while executing the "findAnnotationDescriptor() on MetaCycleAnnotatedClass with missing target meta-annotation" test in MetaAnnotationUtilsTests drops from 16 to 8. Issue: SPR-11483
-
由 Rossen Stoyanchev 提交于
Clarify ability to use @MessageMapping methods on both @Controller as well as @RestController. Add section on configuring connections (including credentials) to the message broker and clarify the use of the login/passcode headerers of the STOMP CONNECT frame. Add note on when to add the reactor-tcp dependency. Issue: SPR-11464, SPR-11436, SPR-11449
-
- 25 2月, 2014 4 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
* SPR-11455: Always supply test class to ContextLoaders in TCF
-
由 Sam Brannen 提交于
Prior to this commit, the following methods in ContextLoaderUtils treated a composed @ContextConfiguration annotation (i.e., a custom annotation that is meta-annotated with @ContextConfiguration) as the "declaring class" instead of the actual test class. - resolveContextConfigurationAttributes() - resolveContextHierarchyAttributes() As a consequence, if @ContextConfiguration is used as a meta-annotation, the meta-annotated class is stored as the "declaringClass" in ContextConfigurationAttributes. Thus, when a ContextLoader (or SmartContextLoader) attempts to detect default resource locations or configuration classes, it does so for the composed annotation class instead of for the declaring test class. This commit ensures that ContextLoaders are supplied the declaring test class instead of the composed annotation class in such use cases. Issue: SPR-11455
-
由 Sam Brannen 提交于
Issue: SPR-11482
-