- 14 4月, 2014 3 次提交
-
-
由 Rossen Stoyanchev 提交于
AbstractMessageConverter and messaging template implementations now detect and use mutable headers if passed in. The SimpMessagingTemplate is optimized to supporting using a single MessageHeaders instance while preparing a message. This commit also updates code using the SimpMessagingTemplate to take advantage of its new capabilities. Issue: SPR-11468
-
由 Rossen Stoyanchev 提交于
Mutate rather than re-create headers when decoding STOMP messages before a message is sent on a message channel. Use MessageBuilder.createMessage to ensure the fully prepared MessageHeaders is used directly MessageHeaderAccessor instance. Issue: SPR-11468
-
由 Rossen Stoyanchev 提交于
Refine semantics of ID and TIMESTAMP headers provided to protected MessageHeaders constructor. Refactor internal implementation of MessageHeaderAccessor. Support mutating headers from a single thread while a message is being built (e.g. StompDecoder creating message + then adding session id). Improve immutablity in NativeMessageHeaderAccessor and in StompHeaderAccessor. Optimize object creation for initializing messages and subsequent accessing their headers. Introduce MessageHeaderAccessorFactory support to enable applying a common strategies for ID and TIMESTAMP generation to every message. Add MessageBuilder shortcut factory method for creating messages from payload and a full-prepared MessageHeaders instance. Also add equivalent constructors to GenericMessage and ErrorMessage. Issue: SPR-11468
-
- 13 4月, 2014 3 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit it was impossible to add additional scripts to a ResourceDatabasePopulator after setScripts() had been invoked. This commit fixes this by ensuring that the internal scripts list continues to be modifiable when setScripts() is invoked. Issue: SPR-11691
-
由 Sam Brannen 提交于
Prior to this commit ResourceDatabasePopulator did not assert any preconditions for constructor and method arguments. Consequently, errors would not be encountered until the populator was executed. This commit addresses this issue by ensuring that preconditions for constructor and method arguments are asserted immediately, throwing IllegalArgumentExceptions where appropriate. Issue: SPR-11690
-
由 Sam Brannen 提交于
-
- 12 4月, 2014 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Changed the value of ScriptUtils.EOF_STATEMENT_SEPARATOR from "<<< END OF SCRIPT >>>" to "^^^ END OF SCRIPT ^^^" so that the angle brackets do not have to be escaped in XML configuration files. Issue: SPR-11687
-
- 11 4月, 2014 5 次提交
-
-
由 Sam Brannen 提交于
Prior to Spring Framework 4.0.3, it was possible to supply a bogus statement separator (i.e., a separator string that does not exist in the configured SQL scripts) to ResourceDatabasePopulator with the side effect that the entire contents of a script file would be interpreted as a single SQL statement. This undocumented feature was never intentional; however, some developers came to rely on it. Unfortunately, changes made in conjunction with SPR-9531 and SPR-11560 caused such scenarios to no longer work. This commit introduces first-class support for executing scripts which contain a single statement that spans multiple lines but is not followed by an explicit statement separator. Specifically, ScriptUtils.EOF_STATEMENT_SEPARATOR may now be specified as a 'virtual' statement separator to denote that a script contains a single statement and no actual separator. Issue: SPR-11687
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
Issue: SPR-11551
-
由 Juergen Hoeller 提交于
Issue: SPR-11680
-
由 Sam Brannen 提交于
-
- 10 4月, 2014 9 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11600
-
由 Juergen Hoeller 提交于
Comes with general JDBC 3.0+ baseline upgrade, removing defensive measures. Issue: SPR-11600
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
* SPR-9955: Introduce context bootstrap strategy in the TCF
-
由 Sam Brannen 提交于
Work done in conjunction with SPR-5243 and SPR-4588 introduced physical package cycles in the spring-test module. The work performed in conjunction with SPR-9924 uses reflection to resolve these physical package cycles; however, prior to this commit the logical package cycles still remain. Furthermore, over time it has become apparent that the Spring TestContext Framework (TCF) could better serve application developers and especially third-party framework developers by providing a more flexible mechanism for "bootstrapping" the TCF. For example, prior to this commit, default TestExecutionListeners could only be registered by subclassing TestContextManager (and SpringJUnit4ClassRunner if using JUnit). Similarly, the default ContextLoader could only be set by subclassing SpringJUnit4ClassRunner for JUnit and by copying and modifying AbstractTestNGSpringContextTests for TestNG. This commit addresses the aforementioned issues by introducing a bootstrap strategy in the TestContext framework that is responsible for determining default TestExecutionListeners and the default ContextLoader in an extensible fashion. The new TestContextBootstrapper SPI also provides a mechanism for supporting various types of MergedContextConfiguration depending on the feature set of the context loaders supported by the strategy. The following provides an overview of the most significant changes in this commit. - Introduced TestContextBootstrapper strategy SPI, BootstrapContext, and @BootstrapWith. - Introduced AbstractTestContextBootstrapper, DefaultTestContextBootstrapper, and WebTestContextBootstrapper implementations of the TestContextBootstrapper SPI and extracted related reflection code from ContextLoaderUtils & TestContextManager. - Introduced BootstrapUtils for retrieving the TestContextBootstrapper from @BootstrapWith, falling back to a default if @BootstrapWith is not present. - @WebAppConfiguration is now annotated with @BootstrapWith(WebTestContextBootstrapper.class). - CacheAwareContextLoaderDelegate is now an interface with a new DefaultCacheAwareContextLoaderDelegate implementation class. - Introduced closeContext(MergedContextConfiguration, HierarchyMode) in CacheAwareContextLoaderDelegate. - DefaultTestContext now uses CacheAwareContextLoaderDelegate instead of interacting directly with the ContextCache. - DefaultTestContext now delegates to a TestContextBootstrapper for building the MergedContextConfiguration. - TestContextManager now delegates to TestContextBootstrapper for retrieving TestExecutionListeners. - Deleted TestContextManager(Class, String) constructor and SpringJUnit4ClassRunner.getDefaultContextLoaderClassName(Class) method since default ContextLoader support is now implemented by TestContextBootstrappers. - Extracted ActiveProfilesUtils from ContextLoaderUtils. - Extracted ApplicationContextInitializerUtils from ContextLoaderUtils. - MetaAnnotationUtils is now a public utility class in the test.util package. - Removed restriction in @ActiveProfiles that a custom resolver cannot be used with the 'value' or 'profiles' attributes. - Introduced DefaultActiveProfilesResolver. Issue: SPR-9955
-
由 Juergen Hoeller 提交于
Issue: SPR-11635 (cherry picked from commit f7a17add)
-
由 Juergen Hoeller 提交于
Issue: SPR-11676 (cherry picked from commit 196f629a)
-
- 09 4月, 2014 7 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11640
-
由 Juergen Hoeller 提交于
Issue: SPR-11637
-
由 Juergen Hoeller 提交于
Issue: SPR-11635
-
由 Juergen Hoeller 提交于
Issue: SPR-11635
-
由 Juergen Hoeller 提交于
Issue: SPR-11678
-
由 Stephane Nicoll 提交于
-
由 Stephane Nicoll 提交于
This commit is a general update of the Cache Abstraction chapter. Existing sections have been updated with recent improvements made in that area, in particular: * Guava and JSR-107 caches support * New @CacheConfig annotation allowing to share some key customizations at class-level * CacheResolver interface used to resolve the cache(s) to use at runtime * Update section on @CachePut This commit also describes the support of standard JCache annotations, i.e. JSR-107. Issues: SPR-11490, SPR-11316, SPR-10629, SPR-9616, SPR-8696
-
- 08 4月, 2014 6 次提交
-
-
由 Stephane Nicoll 提交于
This commit fixes the handling of cached exceptions in the JSR-107 advisor. Such exceptions are now properly propagated instead of being wrapped in a RuntimeException. Issue: SPR-9616
-
由 Stephane Nicoll 提交于
Issue: SPR-11640
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Stephane Nicoll 提交于
Prior to this commit, AnnotatedJCacheableService contained an annotated method demonstrating a failure scenario. This could break depending on the order of the methods array as AopUtils creates the proxy if the pointcut matches by checking each method. On the CI server, the first method was this invalid use case so checking if the proxy has to be created lead to an unexpected exception. This scenario has been moved to its own private class now.
-
由 Stephane Nicoll 提交于
This fixes a Java6 backward compatible issue introduced in the JCache implementation. This commit also adds new representative tests. Issue: SPR-9616
-
- 07 4月, 2014 3 次提交
-
-
由 Stephane Nicoll 提交于
Prior to this commit, the CacheResolver was not used by Spring's caching abstraction. This commit provides the necessary configuration options to tune how a cache is resolved for a given operation. CacheResolver can be customized globally, at the operation level or at the class level. This breaks the CachingConfigurer class and a support implementation is provided that implements all methods so that the default is taken if it's not overridden. The JSR-107 support has been updated as well, with a similar support class. In particular, the static and runtime information of a cache operation were mixed which prevents any forms of caching. As the CacheResolver and the KeyGenerator can be customized, every operation call lead to a lookup in the context for the bean. This commit adds CacheOperationMetadata, a static holder of all the non-runtime metadata about a cache operation. This is used as an input source for the existing CacheOperationContext. Caching the operation metadata in an AspectJ aspect can have side effects as the aspect is static instance for the current ClassLoader. The metadata cache needs to be cleared when the context shutdowns. This is essentially a test issue only as in practice each application runs in its class loader. Tests are now closing the context properly to honor the DisposableBean callback. Issue: SPR-11490
-
由 Stephane Nicoll 提交于
This commit adds support for the JSR-107 cache annotations alongside the Spring's cache annotations, that is @CacheResult, @CachePut, @CacheRemove and @CacheRemoveAll as well as related annotations @CacheDefaults, @CacheKey and @CacheValue. Spring's caching configuration infrastructure detects the presence of the JSR-107 API and Spring's JCache implementation. Both @EnableCaching and the cache namespace are able to configure the required JCache infrastructure when necessary. Both proxy mode and AspectJ mode are supported. As JSR-107 permits the customization of the CacheResolver to use for both regular and exception caches, JCacheConfigurer has been introduced as an extension of CachingConfigurer and permits to define those. If an exception is cached and should be rethrown, it is cloned and the call stack is rewritten so that it matches the calling thread each time. If the exception cannot be cloned, the original exception is returned. Internally, the interceptors uses Spring's caching abstraction by default with an adapter layer when a JSR-107 component needs to be called. This is the case for CacheResolver and CacheKeyGenerator. The implementation uses Spring's CacheManager abstraction behind the scene. The standard annotations can therefore be used against any CacheManager implementation. Issue: SPR-9616
-
由 Sam Brannen 提交于
This commit introduces an explicit integration test to verify that a PropertySource can be set via a custom ApplicationContextInitializer in the Spring TestContext Framework. Issue: SPR-11666
-
- 06 4月, 2014 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-