Rename to PubSubHeaderAccessor and StompHeaderAccessor
Move the renamed classes to support packages
Remove fromPayloadAndHeaders from MessageBuilder, just use
withPayload(..).copyHeaders(..) instead.
To improve compatibility between Spring's messaging classes and
Spring Integration, the type of Message that is created has been made
pluggable through the introduction of a factory abstraction;
MessageFactory.
By default a MessageFactory is provided that will create
org.springframework.messaging.GenericMessage instances, however this
can be replaced with an alternative implementation. For example,
Spring Integration can provide an implementation that creates
org.springframework.integration.message.GenericMessage instances.
This control over the type of Message that's created allows messages
to flow from Spring messaging code into Spring Integration code without
any need for conversion. In further support of this goal,
MessageChannel, MessageHandler, and SubscribableChannel have been
genericized to make the Message type that they deal with more
flexible.
Previously ConfigurationClassParser could override a nested
@Configuration without consideration of @Bean's defined in parent
classes.
This commit ensures that if the original ConfigurationClass contains
additional bean definitions it is processed again.
Issue: SPR-10546
(cherry picked from commit 940011e)
Refactor ConfigurationClassEnhancer so that BeanFactory instances are
not held against CGLIB Callback objects. Enhanced @Configuration classes
now use the BeanFactoryAware interface in order to obtain a BeanFactory.
This change has the additional benefit that a static final field can
now be used to hold all Callback instances.
Issue: SPR-10307
Introduce new @Conditional annotation that can be used to filter
which @Configuration classes or methods are loaded. @Conditional
can be used directly or as a meta-annotation. Condition implementations
are provided via the 'Condition' interface and are free to filter based
on any criteria available at the time that they run. The
ConditionalContext provides access to the BeanDefinitionRegistry,
Environment and ConfigurableListableBeanFactory along with a
ResourceLoader and ClassLoader.
The existing @Profile annotation has been refactored as a @Conditional
with the added benefit that it can now be used as a method level
annotation.
Add PropertySourcesPlaceholderConfigurer.getAppliedPropertySources() to
allow access to the PropertySources that were actually applied.
Issue: SPR-10545
Removed spring-beans.dtd (the 1.x variant) and spring-oxm-1.5.xsd (pre-Spring-Framework variant), in order to raise the backwards compatibility limit a little bit at least. We'll keep supporting the 2.0 and 2.5 xsd versions for the time being, as well as spring-beans-2.0.dtd.
Removed the ref 'local' attribute in spring-beans-4.0.xsd since 'local' lost its differentiating role to a regular bean ref back in the 3.1 days when we started allowing for the same bean id to reappear in a different beans section of the same configuration file (with a different profile).
Issue: SPR-10437
Allow classes that are annotated with @Import to be considered as 'lite'
@Configuration candidates. Allows the AnnotationConfigApplicationContext
to directly register @Import beans even if they are not @Components.
Issue: SPR-10533
Implementations of Spring's ImportSelector interface may
now implement any of the following *Aware interfaces and have their
respective methods called prior to #registerBeanDefinitions:
- BeanFactoryAware
- BeanClassLoaderAware
- ResourceLoaderAware
Issue: SPR-10530
This allows for restoring a static MessageSourceResourceBundleLocator implementation, just implementing the interface at the new spi location introduced in HV 4.3 and preserved in 5.0.
Issue: SPR-8199
Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences.
Issue: SPR-9639
In particular, avoid accidental usage of ASM for core JDK types - which will fail in case of a new bytecode version in the JDK, even if the application itself has been compiled with an earlier bytecode target.
Issue: SPR-10292
* 3.2.x:
Update javadoc external links
JdbcTemplate etc
Removed unnecessary default value of LifecycleGroup.lifecycleBeans
Introduced public ArgumentPreparedStatementSetter and ArgumentTypePreparedStatementSetter classes
Defensively uses JDBC 3.0 getParameterType call for Oracle driver compatibility
Preparations for 3.2.3
Fixed ReflectiveMethodResolver to avoid potential UnsupportedOperationException on sort
Fixed Jaxb2Marshaller's partial unmarshalling feature to consistently apply to all sources
Update copyright year in reference documentation
Conflicts:
build.gradle
gradle.properties
spring-context/src/main/java/org/springframework/context/support/DefaultLifecycleProcessor.java
spring-jdbc/src/main/java/org/springframework/jdbc/core/ArgumentPreparedStatementSetter.java
spring-jdbc/src/main/java/org/springframework/jdbc/core/ArgumentTypePreparedStatementSetter.java
MethodValidationInterceptor autodetects Bean Validation 1.1's ExecutableValidator API now and uses it in favor of Hibernate Validator 4.2's native variant.
SpringConstraintValidatorFactory implements Bean Validation 1.1 "releaseInstance" method against new "destroyBean(Object)" method in AutowireCapableBeanFactory.
LocalValidatorFactoryBean adapts Spring-provided ParameterNameDiscoverer onto Bean Validation 1.1's ParameterNameProvider mechanism.
LocalValidatorFactoryBean reflectively adapts between the different ResourceBundleLocator SPI location in Hibernate Validator 4.2 versus 5.0.
LocalValidatorFactoryBean implements Bean Validation 1.1 "close" method.
Note: We still compile against Bean Validation 1.0 in order to not have to implement "forExecutables()" and "getParameterNameDiscoverer()" in LocalValidatorFactoryBean, SpringValidatorAdapter and CustomValidatorBean. Implementing those methods would imply references to Bean Validation 1.1 interfaces that break runtime compatibility with Bean Validation 1.0. Unfortunately, this means that all Bean Validation 1.1 API access has to be done via reflection.
Issue: SPR-8199
This is built into ConcurrentTaskExecutor and ConcurrentTaskScheduler now, automatically detecting the JSR-236 ExecutorService variants and adapting to them.
Issue: SPR-8195
* 3.2.x: (28 commits)
Hide 'doc' changes from jdiff reports
Document @Bean 'lite' mode vs @Configuration
Final preparations for 3.2.2
Remove Tiles 3 configuration method
Polishing
Extracted buildRequestAttributes template method from FrameworkServlet
Added "beforeExistingAdvisors" flag to AbstractAdvisingBeanPostProcessor
Minor refinements along the way of researching static CGLIB callbacks
Compare Kind references before checking log levels
Polish Javadoc in RequestAttributes
Fix copy-n-paste errors in NativeWebRequest
Fix issue with restoring included attributes
Add additional test for daylight savings glitch
Document context hierarchy support in the TCF
Fix test for daylight savings glitch
Make the methodParameter field of HandlerMethod final
Disable AsyncTests in spring-test-mvc
Reformat the testing chapter
Document context hierarchy support in the TCF
Document context hierarchy support in the TCF
...
Just AsyncAnnotationBeanPostProcessor switches "beforeExistingAdvisors" to "true" by default. So effectively, MethodValidation/PersistenceExceptionTranslationPostProcessor apply after existing advisors by default again, fixing the 3.1->3.2 regression.
Issue: SPR-10309
