- 22 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
In anticipation of substantive changes required to implement "initial delay" support in the <task:scheduled> element and @Scheduled annotation, the following updates have been made to the components and infrastructure supporting scheduled task execution: - Fix code style violations - Fix compiler warnings - Add Javadoc where missing, update to use {@code} tags, etc. - Organize imports to follow conventions
-
- 21 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Prove that Async#value is respected even when using @Async as a meta annotation. Issue: SPR-6847
-
- 20 5月, 2012 2 次提交
-
-
由 Chris Beams 提交于
Prior to this change, Spring's @Async annotation support was tied to a single AsyncTaskExecutor bean, meaning that all methods marked with @Async were forced to use the same executor. This is an undesirable limitation, given that certain methods may have different priorities, etc. This leads to the need to (optionally) qualify which executor should handle each method. This is similar to the way that Spring's @Transactional annotation was originally tied to a single PlatformTransactionManager, but in Spring 3.0 was enhanced to allow for a qualifier via the #value attribute, e.g. @Transactional("ptm1") public void m() { ... } where "ptm1" is either the name of a PlatformTransactionManager bean or a qualifier value associated with a PlatformTransactionManager bean, e.g. via the <qualifier> element in XML or the @Qualifier annotation. This commit introduces the same approach to @Async and its relationship to underlying executor beans. As always, the following syntax remains supported @Async public void m() { ... } indicating that calls to #m will be delegated to the "default" executor, i.e. the executor provided to <task:annotation-driven executor="..."/> or the executor specified when authoring a @Configuration class that implements AsyncConfigurer and its #getAsyncExecutor method. However, it now also possible to qualify which executor should be used on a method-by-method basis, e.g. @Async("e1") public void m() { ... } indicating that calls to #m will be delegated to the executor bean named or otherwise qualified as "e1". Unlike the default executor which is specified up front at configuration time as described above, the "e1" executor bean is looked up within the container on the first execution of #m and then cached in association with that method for the lifetime of the container. Class-level use of Async#value behaves as expected, indicating that all methods within the annotated class should be executed with the named executor. In the case of both method- and class-level annotations, any method-level #value overrides any class level #value. This commit introduces the following major changes: - Add @Async#value attribute for executor qualification - Introduce AsyncExecutionAspectSupport as a common base class for both MethodInterceptor- and AspectJ-based async aspects. This base class provides common structure for specifying the default executor (#setExecutor) as well as logic for determining (and caching) which executor should execute a given method (#determineAsyncExecutor) and an abstract method to allow subclasses to provide specific strategies for executor qualification (#getExecutorQualifier). - Introduce AnnotationAsyncExecutionInterceptor as a specialization of the existing AsyncExecutionInterceptor to allow for introspection of the @Async annotation and its #value attribute for a given method. Note that this new subclass was necessary for packaging reasons - the original AsyncExecutionInterceptor lives in org.springframework.aop and therefore does not have visibility to the @Async annotation in org.springframework.scheduling.annotation. This new subclass replaces usage of AsyncExecutionInterceptor throughout the framework, though the latter remains usable and undeprecated for compatibility with any existing third-party extensions. - Add documentation to spring-task-3.2.xsd and reference manual explaining @Async executor qualification - Add tests covering all new functionality Note that the public API of all affected components remains backward- compatible. Issue: SPR-6847
-
由 Chris Beams 提交于
In anticipation of substantive changes required to implement @Async executor qualification, the following updates have been made to the components and infrastructure supporting @Async functionality: - Fix trailing whitespace and indentation errors - Fix generics warnings - Add Javadoc where missing, update to use {@code} tags, etc. - Avoid NPE in AopUtils#canApply - Organize imports to follow conventions - Remove System.out.println statements from tests - Correct various punctuation and grammar problems
-
- 19 5月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Updated the "@Bean Lite Mode" section in order to properly document scoping and lifecycle semantics. Also fleshed out the discussion of the non-applicability of 'inter-bean references' in lite mode. Issue: SPR-9425
-
- 18 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Commit 180c5b2e introduced 3.2 versions of all spring-* schemas; this commit updates spring.schemas mapping files to include these new versions.
-
- 17 5月, 2012 4 次提交
-
-
由 Philippe Marschall 提交于
This patch fixes several compiler warnings that do not point to code problems. Two kinds of warnings are fixed. First in a lot of cases @SuppressWarnings("unchecked") is used although there are no unchecked casts happening. This seems to be a leftover from when the code base was on Java 1.4, now that the code base was moved to Java 1.5 these are no longer necessary. Secondly there some places where the raw types of List and Class are used where there wildcard types (List<?> and Class<?>) would work just as well without causing any raw type warnings. These changes are beneficial particularly when working in Eclipse or other IDEs because it reduces 'noise', helping to isolate actual potential problems in the code. The following changes have been made: - remove @SuppressWarnings where no longer needed - use wildcard types instead of raw types where possible
-
由 Sam Brannen 提交于
Removed misleading mention of "configuration classes" in the "@Bean Lite Mode" section. Issue: SPR-9401
-
由 Sam Brannen 提交于
Updated the class-level JavaDoc for @Bean to better explain the semantics of 'lite' mode. Renamed "Configuration Class Lite Mode" to "@Bean Lite Mode". Added discussion of @DependsOn to the class-level JavaDoc. Issue: SPR-9401
-
由 Sam Brannen 提交于
Overhauled the class-level JavaDoc in @Bean: - added h3 headers for greater clarity and readability - mentioned 'prototype' semantics for lite mode Issue: SPR-9401
-
- 16 5月, 2012 2 次提交
-
-
由 Chris Beams 提交于
It is now advised that destroyMethod="shutdown" should be used on @Bean methods returning an ExecutorService. Issue: SPR-9280
-
由 Sam Brannen 提交于
-
- 01 5月, 2012 1 次提交
-
-
由 Dridi Boukelmoune 提交于
Prior to this change, request-scoped components having @Resource-injected dependencies caused a memory leak in DefaultListableBeanFactory#dependenciesForBeanMap. Consider the following example: @Component @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS) public class MyComponent { @resource private HttpServletRequest request; // ... } The bean name for "MyComponent" will end up being 'scopedTarget.myComponent', which will become a key in the #dependenciesForBeanMap structure. On the first request, the injected HttpServletRequest bean will be a proxy and will internally have a bean name of the form "$Proxy10@1a3a2a52". This name will be added to the Set value associated with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap. On the second request, the process will repeat, but the injected HttpServletRequest will be a different proxy instance, thus having a different identity hex string, e.g. "$Proxy10@5eba06ff". This name will also be added to the Set value associated with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this is the source of the leak: a new entry is added to the set on each request but should be added only once. This commit fixes the leak by introducing caching to CommonAnnotationBeanPostProcessor#ResourceElement similar to that already present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement and #AutowiredMethodElement. Essentially, each ResourceElement instance now tracks whether it has been created, caches the ultimate value to be injected and returns it eagerly if necessary. Besides solving the memory leak, this has the side effect of avoiding unnecessary proxy creation. This fix also explains clearly why injection into request-scoped components using @Autowired never suffered this memory leak: because the correct caching was already in place. Because @resource is considerably less-frequently used than @Autowired, and given that this particular injection arrangement is relatively infrequent, it becomes understandable how this bug has been present without being reported since the introduction of @resource support in Spring 2.5: developers were unlikely to encounter it in the first place; and if they did, the leak was minor enough (adding strings to a Set), that it could potentially go unnoticed indefinitely depending on request volumes and available memory. Issue: SPR-9176
-
- 30 4月, 2012 1 次提交
-
-
由 Stevo Slavic 提交于
Before this change there were numerous javadoc warnings being reported while building Spring framework API. This commit resolves most of the javadoc warnings, reducing the total number from 265 to 103. Issue: SPR-9113
-
- 27 3月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no substantive changes, but rather prepares for them by creating a clean baseline. All internal references to 3.1 schemas (e.g. spring-tool) have also been updated.
-
- 09 3月, 2012 1 次提交
-
-
由 Chris Beams 提交于
With thanks to @abdull for pull request #55
-
- 22 2月, 2012 1 次提交
-
-
由 Stevo Slavic 提交于
Prior to this change, before a bean is created by EhCacheFactoryBean, its #getObjectType would return only an Ehcache interface. This caused unwanted wiring issues as described in the related JIRA issue. This fix makes use of EhCacheFactoryBean's configuration to determine the specific Ehcache object type even before it's created, such that the container is provided with as much information as possible when resolving dependencies. Nevertheless, users are advised to code to the Ehcache interface. Issue: SPR-7843
-
- 20 2月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Changes in commit 41ade68b introduced a regression causing all but the first location in the @PropertySource#value array to be ignored during ${...} placeholder resolution. This change ensures that all locations are processed and replaced as expected. Issue: SPR-9133, SPR-9127
-
- 31 1月, 2012 2 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-