- 22 5月, 2012 5 次提交
-
-
由 Chris Beams 提交于
* SPR-7022: Support initial delay attribute for scheduled tasks Polish scheduled task execution infrastructure
-
由 Chris Beams 提交于
java.util.concurrent's ScheduledExecutorService and its #schedule* methods allow for an 'initialDelay' parameter in milliseconds. Similarly, Spring's TaskExecutor abstraction allows for a concrete 'startTime' expressed as a Date. However, Spring's <task:scheduled> XML element and @Scheduled annotation have, to date, not allowed for an initial delay parameter that can be propagated down to the underlying TaskScheduler/ScheduledExecutorService. This commit introduces initial-delay and #initialDelay attributes to task:scheduled and @Scheduled respectively, both indicating the number of milliseconds to wait before the first invocation of the method in question. Specifying a delay in this fashion is only valid in conjunction with fixed-rate and fixed-delay tasks (i.e. not with cron or trigger tasks). The principal changes required to support these new attributes lie in ScheduledTaskRegistrar, which previously supported registration of tasks in the form of a Runnable and a Long parameter indicating (in the case of fixed-rate and fixed-delay tasks), the interval with which the task should be executed. In order to accommodate a third (and optional) 'initialDelay' parameter, the IntervalTask class has been added as a holder for the Runnable to be executed, the interval in which to run it, and the optional initial delay. For symmetry, a TriggerTask and CronTask have also been added, the latter subclassing the former. And a 'Task' class has been added as a common ancestor for all the above. One oddity of the implementation is in the naming of the new setters in ScheduledTaskRegistrar. Prior to this commit, the setters were named #setFixedDelayTasks, #setFixedRateTasks, etc, each accepting a Map<Runnable, long>. In adding new setters for each task type, each accepting a List<IntervalTask>, List<CronTask> etc, naturally the approach would be to use method overloading and to introduce methods of the same name but with differing parameter types. Unfortunately however, Spring does not support injection against overloaded methods (due to fundamental limitations of the underlying JDK Introspector). This is not a problem when working with the ScheduledTaskRegistrar directly, e.g. from within a @Configuration class that implements SchedulingConfigurer, but is a problem from the point of view of the ScheduledTasksBeanDefinitionParser which parses the <task:scheduled> element - here the ScheduledTaskRegistrar is treated as a Spring bean and is thus subject to these limitations. The solution to this problem was simply to avoid overloading altogether, thus the naming of the new methods ending in "List", e.g. #setFixedDelayTasksList, etc. These methods exist primarily for use by the BeanDefinitionParser and are not really intended for use by application developers. The Javadoc for each of the new methods makes note of this. Issue: SPR-7022
-
由 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
-
由 Chris Beams 提交于
* SPR-9300: Add convenient WebAppInitializer base classes
-
由 Arjen Poutsma 提交于
This commit introduces three abstract WebApplicationInitializers, to be used in the typical setup of a Spring-based web application. - AbstractContextLoaderInitializer provides an abstract base class for registering a ContextLoaderListener. - AbstractDispatcherServletInitializer provides an abstract base class for registering a DispatcherServlet, with an optional root context. - AbstractAnnotationConfigDispatcherServletInitializer provides an abstract base class for registering a DispatcherServlet and optional ContextLoaderListener based on annotated (e.g. @Configuration) classes. Issue: SPR-9300
-
- 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 4 次提交
-
-
由 Chris Beams 提交于
* SPR-6847: Support executor qualification with @Async#value Polish async method execution infrastructure Refactor and deprecate TransactionAspectUtils
-
由 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
-
由 Chris Beams 提交于
TransactionAspectUtils contains a number of methods useful in retrieving a bean by type+qualifier. These methods are functionally general-purpose save for the hard coding of PlatformTransactionManager class literals throughout. This commit generifies these methods and moves them into BeanFactoryUtils primarily in anticipation of their use by async method execution interceptors and aspects when performing lookups for qualified executor beans e.g. via @Async("qualifier"). The public API of TransactionAspectUtils remains backward compatible; all methods within have been deprecated, and all calls to those methods throughout the framework refactored to use the new BeanFactoryUtils variants instead.
-
- 19 5月, 2012 4 次提交
-
-
由 Sam Brannen 提交于
The reference manual previously did not mention the applicability of JSR-250 lifecycle annotations within the TestContext framework. The lacking documentation here has lead to misunderstandings of the support provided for @PostConstruct and @PreDestroy in test classes. The testing chapter of the reference manual has therefore been updated to explicitly define the limited support for these annotations. Also introduced Jsr250LifecycleTests for empirical verification of the expected behavior. Issue: SPR-4868
-
由 Rossen Stoyanchev 提交于
There is usually not need to put annotations on a WebDataBinder argument in an `@InitBinder` method. However, the presence of any annotation prevented the successful resolution of the argument. This fix addresses the issue. Issue: SPR-8946
-
由 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
-
由 Sam Brannen 提交于
Introduced AtBeanLiteModeScopeTests integration tests to verify proper scoping of beans created in 'lite' mode. Updated comments in TACCWithoutACTests to better reflect the runtime behavior for 'lite' @Bean methods. Issue: SPR-9401
-
- 18 5月, 2012 11 次提交
-
-
由 Sam Brannen 提交于
Revised the content in the @ContextConfiguration annotation section. Issue: SPR-9401
-
由 Chris Beams 提交于
* SPR-9249: Add value-type attrib to beans->map->entry element
-
由 Gary Russell 提交于
Previously, the <value> subelement of a map <entry> allowed one to specify the type of a specific map entry value. This patch allows a value-type attribute as well, such that instead of the following syntax <entry key="x-message-ttl"> <value type="java.lang.Long">100</value> </entry> <entry key="x-ha-policy" value="all" /> one can now use the more concise form <entry key="x-message-ttl" value="100" value-type="java.lang.Long"/> <entry key="x-ha-policy" value="all"/> The new value-type attribute may be used at the <map> level as well, indicating that all elements are of the same type. Appropriate tests have been added exercising value-type at the <map> and <entry> levels. Issue: SPR-9249
-
由 Chris Beams 提交于
Commit 180c5b2e introduced 3.2 versions of all spring-* schemas; this commit updates spring.schemas mapping files to include these new versions.
-
由 Sam Brannen 提交于
Updated the testing chapter of the reference manual to refer to 'annotated classes' instead of 'configuration classes' where appropriate. Also revised the content and examples in the @ContextConfiguration annotation section, mentioned Gradle, and reformatted the entire text. Issue: SPR-9401
-
由 Sam Brannen 提交于
Several test methods in RequestResponseBodyMethodProcessorTests are currently annotated with @test(expected=…) and additionally contain: fail("Expected exception"); This combination is superfluous, and the unnecessary fail() invocations have therefore been removed.
-
由 Rossen Stoyanchev 提交于
If true and there is no body => HttpMessageNotReadableException If false and there is no body, the argument resolves to null. Issue: SPR-9239
-
由 Rossen Stoyanchev 提交于
See the commit comments for: https://github.com/SpringSource/spring-framework/commit/57307a0b2e5bce8f70d5deddf8df11d034dc8c5a This commit also applies the change to pre-3.1 `@mvc` suppor classes. Issue: SPR-6951
-
由 Rossen Stoyanchev 提交于
When URL decoding is turned off in AbstractHandlerMapping, the extracted path variables are also not encoded. Turning off URL decoding may be necessary for request mapping to work correctly when the path may contain the (encoded) special character '/'. At the same time there is no good reason not to leave path variables encoded. This change ensures path variables are encoded when URL decoding is turned off. Issue: SPR-9098
-
由 Sam Brannen 提交于
Updated all Javadoc in the Spring TestContext Framework (TCF) to explain and refer to 'annotated classes' instead of 'configuration classes'. Specifically, @ContextConfiguration now explicitly defines what is meant by 'annotated classes', and various other classes now refer to this definition. Otherwise, the term 'configuration class' has simply been replaced with 'annotated class'. Also deleted cross references to deprecated JUnit 3.8 classes and formatted Javadoc in general for greater readability. Issue: SPR-9401
-
由 Sam Brannen 提交于
Reordered inline comments so that they now apply to current state of the code. Added logger entry in testlog4j.properties to avoid console warning. Issue: SPR-9417
-
- 17 5月, 2012 15 次提交
-
-
由 Chris Beams 提交于
* SPR-5369: Fix circular placeholder prevention
-
由 Stevo Slavic 提交于
A set of resolved placeholder references is used for circular placeholder prevention. For complex property definitions this mechanism would put property values with unresolved inner placeholder references in the set, but would try to remove property values with placeholders resolved, leaving the set in an invalid state and the mechanism broken. This fix makes sure that the value that is put in the set is same one that is removed from it, and by doing so avoids false positives in reporting circular placeholders. Issue: SPR-5369
-
由 Chris Beams 提交于
* warnings: Fix compiler warnings
-
由 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
-
由 Chris Beams 提交于
* SPR-9203: Eliminate trailing whitespace in SpEL classes Support [] array ref syntax in SpEL T() construct
-
由 Chris Beams 提交于
-
由 Andy Clement 提交于
Prior to this change, SpEL would not allow the use of '[]' in expressions like the following: T(foo.Bar[]) This commit updates TypeReference and InternalSpelExpressionParser to support this syntax, avoiding the need for workarounds like: new foo.bar[0].class Issue: SPR-9203
-
由 Chris Beams 提交于
* SPR-8278: Fix compiler warnings in Constants/ConstantsTests Allow null params as advertised in Constants#toCode*
-
由 Chris Beams 提交于
-
由 Stevo Slavic 提交于
Even though the Javadoc for Constants#toCode and #toCodeForSuffix specifies that a null value for the 'namePrefix' and 'nameSuffix' parameters are respectively allowed, before this change passing a null to either would result in a NullPointerException. This change fixes constant name lookup for null values of these params as if an empty string had been passed instead. This way of handling a null value is consistent with the rest of Constants class API. Issue: SPR-8278
-
由 Chris Beams 提交于
* SPR-8360: Fix JibxMarshallerTests failing on Windows
-
由 Stevo Slavic 提交于
Before this change JibxMarshallerTests would fail on Windows with an error message explaining that JiBX compiler generated classes are not found on the classpath for binding with name 'binding'. Tests would execute well on Linux and OS X. Actual root cause of this bug is found to be in JiBX 1.1.5 release that is used to build Spring. The binding name can be explicitly specified in JiBX binding file. If omitted, when generating classes the JiBX compiler as fall-back mechanism tries to derive the binding name from the binding file name. That logic had a bug which gets manifested when configured binding file path has mixed Windows and *nix style file separators, as in case of JibxMarshallerTests being executed on a Windows platform. This commit resolves this issue by upgrading Spring's build from JiBX 1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441 for more details. Issue: SPR-8360
-
由 Chris Beams 提交于
* SPR-9123: Fix SpEL JavaBean compliance
-
由 Stevo Slavic 提交于
Before this fix ReflectivePropertyAccessor was not able to find write method for valid property name that has first character in lower case and second character in upper case. Write method lookup would always convert first character of property name to upper case which is not compliant with JavaBean specification. As consequence this caused an unwanted behavior in SpEL when obtaining values of expressions that reference such JavaBean properties. As of this change, write method lookup skips conversion of property name first character to upper case when property name is longer than one character and second character is in upper case. This also fixes mentioned bug in SpEL value resolution. Issue: SPR-9123
-
由 Chris Beams 提交于
Previously, if the resolution of a ${...} placeholder resulted in a valid URL for the location of a log4j properties/XML file, the URL would ultimately be malformed by an unnecessary call to to WebUtils#getRealPath. The implementation of Log4jWebConfigurer#initLogging now eagerly attempts SystemPropertyUtils#resolvePlaceholders before checking to see if the location is a valid URL, and bypassing the call to WebUtils#getRealPath if so. Issue: SPR-9417
-