src-spring-framework

Commit Graph

Author	SHA1	Message	Date
Phillip Webb	a9a90cabad	Protect against non-deterministic method order in JDK7 - Allow reset of GlobalAdvisorAdapterRegistry Provide a reset() method allowing the GlobalAdvisorAdapterRegistry instance to be replaced with a fresh instance. This method has primarily been added to allow unit tests to leave the registry in a known state. - Protect against the fact that calls to configuration class methods my occur in a random order. Issue: SPR-9779	12 years ago
Juergen Hoeller	430db261e7	BeanFactoryAnnotationUtils throws NoSuchBeanDefinitionExceptions instead of IllegalStateExceptions Issue: SPR-9652	12 years ago
Phillip Webb	77c9321967	Sort candidate @AspectJ methods deterministically Update the ReflectiveAspectJAdvisorFactory class to sort candidate AOP methods based on their annotation first and method name second. Prior to this the order of aspects created from annotated methods could differ depending on the underling JVM, as first noticed under JDK7 in SPR-9729. - ConvertingComparator and InstanceComparator have been introduced in support of this change, per SPR-9730. - A shared static INSTANCE field has been added to ComparableComparator to avoid unnecessary instantiation costs within ConvertingComparator as well as to prevent generics warnings during certain caller scenarios. Issue: SPR-9729, SPR-9730	12 years ago
Chris Beams	92500ab902	Upgrade to CGLIB 3 and inline into spring-core CGLIB 3 has been released in order to depend on ASM 4, which Spring now depends on internally (see previous commit). This commit eliminates spring-beans' optional dependency on cglib-nodep v2.2 and instead repackages net.sf.cglib => org.springframework.cglib much in the same way we have historically done with ASM. This change is beneficial to users in several ways: - Eliminates the need to manually add CGLIB to the application classpath; especially important for the growing number of @Configuration class users. Java-based configuration functionality, along with proxy-target-class and method injection features now work 'out of the box' in Spring 3.2. - Eliminates the possibility of conflicts with other libraries that may dependend on differing versions of CGLIB, e.g. Hibernate 3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a conflict if the application were depending on CGLIB 3 for Spring-related purposes. - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is that much less likely to work well in a Java 7 environment due to ASM 4's support for transforming classes with invokedynamic bytecode instructions. On CGLIB and ASM: CGLIB's own dependency on ASM is also transformed along the way to depend on Spring's repackaged org.springframework.asm, primarily to eliminate unnecessary duplication of ASM classfiles in spring-core and in the process save around 100K in the final spring-core JAR file size. It is coincidental that spring-core and CGLIB currently depend on the exact same version of ASM (4.0), but it is also unlikely to change any time soon. If this change does occur and versions of ASM drift, then the size optimization mentioned above will have to be abandoned. This would have no compatibility impact, however, so this is a reasonable solution now and for the forseeable future. On a mysterious NoClassDefFoundError: During the upgrade to CGLIB 3.0, Spring test cases began failing due to NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter regarding its use of asm-util's TraceClassVisitor type. previous versions of cglib-nodep, particularly 2.2, did not cause this behavior, even though cglib-nodep has never actually repackaged and bundled asm-util classes. The reason for these NoClassDefFoundErrors occurring now is still not fully understood, but appears to be due to subtle JVM bytecode preverification rules. The hypothesis is that due to minor changes in DebuggingClassWriter such as additional casts, access to instance variables declared in the superclass, and indeed a change in the superclass hierarchy, preverification may be kicking in on the toByteArray method body, at which point the reference to the missing TraceClassVisitor type is noticed and the NCDFE is thrown. For this reason, a dummy implementation of TraceClassVisitor has been added to spring-core in the org.springframework.asm.util package. This class simply ensures that Spring's own tests never result in the NCDFE described above, and more importantly that Spring's users never encounter the same. Other changes include: - rename package-private Cglib2AopProxy => CglibAopProxy - eliminate all 'cglibAvailable' checks, warnings and errors - eliminate all 'CGLIB2' language in favor of 'CGLIB' - eliminate all mention in reference and java docs of needing to add cglib(-nodep) to one's application classpath Issue: SPR-9669	12 years ago
Chris Beams	f6de5d4360	Reflect @Async executor qual. 3.2=>3.1.2 backport @Async executor qualification has been backported to 3.1.2. This commit updates all @since tags appropriately, as well as carrying over the changes backported to the spring-task-3.1 schema. Issue: SPR-6847, SPR-9443	13 years ago
Chris Beams	a4b00c732b	Introduce BeanFactoryAnnotationUtils Commit `096693c46f` refactored and deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType and related methods into BeanFactoryUtils. This created a package cycle between beans.factory and beans.factory.annotation due to use of the beans.factory.annotation.Qualifier annotation in these methods. This commit breaks the package cycle by introducing beans.factory.annotation.BeanFactoryAnnotationUtils and moving these @Qualifier-related methods to it. It is intentionally similar in name and style to the familiar BeanFactoryUtils class for purposes of discoverability. There are no backward-compatibilty concerns associated with this change as the cycle was introduced, caught and now fixed before a release. Issue: SPR-6847	13 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	13 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	13 years ago
Chris Beams	f3bcb6e2e4	Update spring.schemas to reflect 3.2 schemas Commit `180c5b2ef6` introduced 3.2 versions of all spring-* schemas; this commit updates spring.schemas mapping files to include these new versions.	13 years ago
Philippe Marschall	13239a0c3d	Fix compiler warnings 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	13 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	13 years ago
Chris Beams	180c5b2ef6	Introduce 3.2 versions of Spring XML namespaces 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.	13 years ago
Chris Beams	6235a341a7	Remove bundlor support	13 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	13 years ago

... 4 5 6 7 8

377 Commits (e3fa4e13503f5cb1427c308b6044140c6b016979)