HibernateJpaDialect's HibernateConnectionHandle does not call close() for Hibernate 4.x anymore, since on 4.2, the exposed Connection handle isn't a "borrowed connection" wrapper but rather the actual underlying Connection - with a close() call immediately returning the Connection to the pool and making the local handle invalid for further use within the transaction.
Also using JPA 2.0's EntityManager unwrap method now for retrieving the underlying Hibernate Session.
Issue: SPR-10395
In the course of this effort, our joinTransaction() support has been overhauled to work for shared EntityManagers as well, since an unsynchronized shared EntityManager will nevertheless be scoped for the current transaction but not automatically join it (as per the JPA 2.1 spec). In the JTA case, we'll simply create an unsynchronized target EntityManager and will upgrade it to a synchronized one (later in the same transaction, if necessary) through an implicit joinTransaction() call. In the JpaTransactionManager case, we'll unbind the primary target EntityManager and will expose an unsynchronized EntityManager instead, upgrading it the same way as with JTA, with the primary EntityManager in that case just serving as a vehicle for transaction begin/commit/rollback calls.
For extended EntityManagers, we've just added further combinations to the existing variants: application-managed EntityManagers which may nevertheless auto-join transactions (EntityManagerFactory.createEntityManager with SynchronizationType.SYNCHRONIZED), and container-managed EntityManagers which might opt for not auto-joining transactions (@PersistenceContext with synchronizationType=UNSYNCHRONIZED).
Issue: SPR-8194
Also introduces consistent use of getBean(Class) for similar use cases across the framework, accepting a locally unique target bean even if further matching beans would be available in parent contexts (in contrast to BeanFactoryUtils.beanOfType's behavior).
Issue: SPR-10160
Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.
In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.
In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).
- 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
Previously reflection was required when interacting with Hibernate 4 in
order to support both Hibernate 3 and Hibernate 4 since there were
non-passive changes in the APIs. Now that the Spring build uses Gradle
it is trivial to support multiple Hibernate versions.
This commit removes the reflection usage in orm.hibernate4.* by
creating a spring-orm-hibernate4 module that uses
gradle/merge-artifacts.gradle to build a single artifact but keep
distinct classpaths.
Issue: SPR-10039
New afterTimeout and afterCompletion callbacks
afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time
Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result
Adapter classes for convenient implementation of the interfaces
Issue: SPR-9914
This change introduces two new interceptors with callback methods
for concurrent request handling. These interfaces are
CallableProcessingInterceptor and DeferredResultProcessingInterceptor.
Unlike a HandlerInterceptor, and its AsyncHandlerInterceptor sub-type,
which intercepts the invocation of a handler in he main request
processing thread, the two new interfaces are aimed at intercepting the
asynchronous execution of a Callable or a DeferredResult.
This allows for the registration of thread initialization logic in the
case of Callable executed with an AsyncTaskExecutor, or for centralized
tracking of the completion and/or expiration of a DeferredResult.
This change fixes a cyclical package dependency.
The change also improves the implementation of
WebAsyncManager.hasConcurrentResult() following the resolution of
Apache issue id=53632 and the release of Apache Tomcat 7.0.30 that
contains the fix.
Carson McDonald
Rob Winch
Juergen Hoeller
Chris Beams
Sam Brannen
Phillip Webb
Rossen Stoyanchev