spring-framework

Commit Graph

Author	SHA1	Message	Date
Chris Beams	8472a2b2ab	Update Apache license headers for affected sources	13 years ago
Phillip Webb	6c14eaad61	Fix [cast] compiler warnings	13 years ago
Chris Beams	9540d2c81b	Replace <code> with {@code} throughout Javadoc Issue: SPR-10128	13 years ago
Chris Beams	8597ec25ec	Fix various Javadoc warnings Issue: SPR-10128	13 years ago
Phillip Webb	2cf45bad86	Replace space indentation with tabs Issue: SPR-10127	13 years ago
Phillip Webb	1762157ad1	Remove trailing whitespace in source files find . -type f -name ".java" -or -name ".aj" \| \ xargs perl -p -i -e "s/[ \t]*$//g" {} \; Issue: SPR-10127	13 years ago
Chris Beams	f26534700a	Eliminate all Javadoc warnings - Support external Javadoc links using Gradle's javadoc.options.links - Fix all other Javadoc warnings, such as typos, references to non-existent (or no longer existent) types and members, etc, including changes related to the Quartz 2.0 upgrade (SPR-8275) and adding the HTTP PATCH method (SPR-7985). - Suppress all output for project-level `javadoc` tasks in order to hide false-negative warnings about cross-module @see and @link references (e.g. spring-core having a @see reference to spring-web). Use the `--info` (-i) flag to gradle at any time to see project-level javadoc warnings without running the entire `api` task. e.g. `gradle :spring-core:javadoc -i` - Favor root project level `api` task for detection of legitimate Javadoc warnings. There are now zero Javadoc warnings across the entirety of spring-framework. Goal: keep it that way. - Remove all @link and @see references to types and members that exist only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+ respectively. This is necessary because only one version of each of these dependencies can be present on the global `api` javadoc task's classpath. To that end, the `api` task classpath has now been customized to ensure that the Servlet 3 API and Hibernate Core 4 jars have precedence. - SPR-8896 replaced our dependency on aspectjrt with a dependency on aspectjweaver, which is fine from a POM point of view, but causes a spurious warning to be emitted from the ant iajc task that it "cannot find aspectjrt on the classpath" - even though aspectjweaver is perfectly sufficient. In the name of keeping the console quiet, a new `rt` configuration has been added, and aspectjrt added as a dependency to it. In turn, configurations.rt.asPath is appended to the iajc classpath during both compileJava and compileTestJava for spring-aspects. Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896	14 years ago
Phillip Webb	da50a0213b	Polish Javadoc Minor Javadoc reformat to prevent erroneous eclipse warnings	14 years ago
Chris Beams	54db7387de	Fix split package introduced by @EnableSpringConfigured Commit `5327a7a37d` moved @EnableSpringConfigured from beans.factory.aspectj => context.annotation within the spring-aspects module. This resolved a package cycle but had the side-effect of causing a "split package" [1] problem between spring-context and spring-aspects in OSGi-based classloader environments because the context.annotation package now exists in both modules. The simplest and best solution from an OSGi perspective is to relocate @EnableSpringConfigured and its supporting SpringConfiguredConfiguration class into a new package. This commit moves both these types into context.annotation.aspectj, following convention with other such "aspectj"-qualified packages in the spring-aspects module. As with the previous move, it is presumed this change will be low-impact as the "spring-configured" approach to domain object injection is a niche feature to begin with, and @EnableSpringConfigured has existed in its current location only since 3.1.2 and this change is being made in time for 3.1.3. [1]: http://wiki.osgi.org/wiki/Split_Packages Issue: SPR-9811, SPR-9441	14 years ago
Chris Beams	5327a7a37d	Fix package cycle in @EnableSpringConfigured @EnableSpringConfigured and its @Import'ed SpringConfiguredConfiguration @Configuration class inadvertently established a package cycle between beans.factory.aspectj and context.annotation due to SpringConfiguredConfiguration's dependency on annotations such as @Configuration, @Bean and @Role. This commit fixes this architecture bug by moving @EnableSpringConfigured and SpringConfiguredConfiguration from the beans.factory.aspectj package to the context.annotation package where they belong. This change is assumed to be very low impact as @EnableSpringConfigured was introduced in 3.1.0 and relocation is happening as quickly as possible in 3.1.2. @EnableSpringConfigured is assumed to be infrequently used at this point, and for those that are the migration path is straightforward. When upgrading from Spring 3.1.0 or 3.1.1, update import statements in any affected @Configuration classes to reflect the new packaging. Issue: SPR-9441	14 years ago
Chris Beams	ed0576c181	Support executor qualification with @Async#value 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	14 years ago
Chris Beams	3fb11870d9	Polish async method execution infrastructure 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	14 years ago
Stevo Slavic	effb762558	Fix javadoc warnings 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	14 years ago
Chris Beams	02a4473c62	Rename modules {org.springframework.=>spring-} 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	14 years ago

14 Commits (b8f408ed5faae1bf266331063bc2ea575962bead)