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
* 3.1.x: Demonstrate use of @Configuration as meta-annotation Prune dead code from JmsTransactionManager#doBegin Apply @Configuration BeanNameGenerator consistently Improve @Configuration bean name discovery Fix infinite recursion bug in nested @Configuration Polish static imports Minor fix in ServletResponseMethodArgumentResolver extracted ResourceUtils.useCachesIfNecessary(URLConnection) method (SP prepared for 3.1.1 release CustomSQLExceptionTranslatorRegistry/Registrar etc revised CustomSQLExceptionTranslatorRegistry/Registrar method naming use custom InputStream traversal instead of a full byte array (SPR-911 PathMatchingResourcePatternResolver preserves caching for JNLP jar con Resource "contentLength()" implementations work with OSGi bundle resou fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz
* 3.1.x: (61 commits) Compensate for changes in JDK 7 Introspector Avoid 'type mismatch' errors in ExtendedBeanInfo Polish ExtendedBeanInfo and tests Infer AnnotationAttributes method return types Minor fix in MVC reference doc chapter Hibernate 4.1 etc TypeDescriptor equals implementation accepts annotations in any order "setBasenames" uses varargs now (for programmatic setup; SPR-9106) @ActiveProfiles mechanism works with @ImportResource as well (SPR-8992 polishing clarified Resource's "getFilename" method to consistently return null substituteNamedParameters detects and unwraps SqlParameterValue object Replace spaces with tabs Consider security in ClassUtils#getMostSpecificMethod Adding null check for username being null. Improvements for registering custom SQL exception translators in app c SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera Minor polish in WebMvcConfigurationSupport Detect overridden boolean getters in ExtendedBeanInfo Polish ExtendedBeanInfoTests ...
This is the first merge from 3.1.x => master after the Gradle build system migration. Notice how files changed under the 3.1.x directory structure (org.springframework.*) merge seamlessly into the new directory structure (spring-*). Certain files had changed under 3.1.x that have since been deleted with the Gradle build migration, e.g. all pom.xml files had <license> sections added. These files showed up as a conflict during the merge, but the resolution is to simply re-remove them and commit as they are no longer relevant under 3.2.x / master. Also noteworthy is the .gitignore file. It has been updated under 3.1.x to ignore files and directories specific to the new Gradle-based structure. However, this causes conflicts when trying to merge against master, given that master should *not* ignore this directories. The resolution in this situation is to simply force the 'master' version of the file, i.e. when prompted for merge resolution: anakata:~/Work/spring-framework/spring-framework[master|MERGING] $ git status -sb ## master...springsource/master [ahead 24] UU .gitignore anakata:~/Work/spring-framework/spring-framework[master|MERGING] $ git checkout master .gitignore anakata:~/Work/spring-framework/spring-framework[master|MERGING] $ git commit It is helpful in situations like this one to enable git's "rerere" feature beforehand, which records and remembers resolution strategies, avoiding the need to repeat them in future merges: $ git config --global rerere.enabled 1 See: http://progit.org/2010/03/08/rerere.html http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time Conflicts: .gitignore .springframework.*/pom.xml
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