Fix PersistenceUnitReader to correctly read <exclude-unlisted-classes>
in both JPA 1.0 and 2.0 persistence.xml files.
Prior to this commit PersistenceUnitReader would set the value of
excludeUnlistedClasses to true when a <exclude-unlisted-classes> element
was present, regardless of its value.
The following rules are now used when parsing:
- If the <exclude-unlisted-classes> element is missing the appropriate
default value is set (based on the JPA version).
- If an empty <exclude-unlisted-classes/> element is found the
excludeUnlistedClasses property is set to true.
- Otherwise the value of the <exclude-unlisted-classes> element is used
to set the excludeUnlistedClasses property.
Issue: SPR-10767
Fix SharedEntityManagerCreator.createSharedEntityManager to correctly
forward an empty array in case that EntityManagerFactoryInfo returns
null from getEntityManagerInterface().
Previously the var-args invocation had turned null into an array with
a null value which caused a NullPointerException in the call to
Proxy.newProxyInstance() further down the call stack.
Issue: SPR-10678
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
The files deleted in this commit existed in identical form in two places
within a given module; typically in src/test/java and
src/test/resources. The version within src/test/resources has been
favored in all cases.
This change was prompted by associated Eclipse warnings, which have now
been quelled.
Issue: SPR-9431
Prior to this commit many test utility classes and sample beans were
duplicated across projects. This was previously necessary due to the
fact that dependent test sources were not shared during a gradle
build. Since the introduction of the 'test-source-set-dependencies'
gradle plugin this is no longer the case.
This commit attempts to remove as much duplicate code as possible,
co-locating test utilities and beans in the most suitable project.
For example, test beans are now located in the 'spring-beans'
project.
Some of the duplicated code had started to drift apart when
modifications made in one project where not ported to others. All
changes have now been consolidated and when necessary existing tests
have been refactored to account for the differences.
Conflicts:
spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java
spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java
Fix deprecation compiler warnings by refactoring code or applying
@SuppressWarnings("deprecation") annotations. JUnit tests of
internally deprecated classes are now themselves marked as
@Deprecated.
Numerous EasyMock deprecation warnings will remain until the
migration to mockito can be completed.
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.
Documented why static nested test cases in the spring-test module are
ignored, explaining that such "TestCase classes are run manually by the
enclosing test class". Prior to the migration to Gradle (i.e., with
Spring Build), these tests would not have been picked up by the test
suite since they end with a "TestCase" suffix instead of "Test" or
"Tests".
Re-enabled HibernateMultiEntityManagerFactoryIntegrationTests.
For the remaining tests that were disabled as a result of the migration
to Gradle, comments have been added to the @Ignore declarations.
Issue: SPR-8116, SPR-9398
Previously when running the tests for spring-web, spring-webmvc,
spring-test-mvc, and spring-orm there were possible collissions in the
classpath due to the fact that each had its own copy of the web.Mock*
classes in it. This causes uncertainty for which class the code was
running against. Furthermore, the maintance of keeping the copies up to
date was tedious.
Now there are two copies of the web.Mock* classes. The ones that exist
in spring-test main sources and a copy that supports servlet 3 within
spring-web test sources. The copy in spring-web test sources has been
moved to a new package to avoid having the classes exist twice on the
classpath within Eclipse.
Prior to this commit the MockHttpServletRequest constructor chain set
the preferred local to Locale.ENGLISH. Furthermore, it was possible to
add additional preferred locales "in front" of ENGLISH; however, it was
not possible to delete ENGLISH from the list of preferred locales.
This commit documents the fact that ENGLISH is the default preferred
locale and makes it possible to set the list of preferred locales via a
new setPreferredLocales(List<Locale> locales) method.
Issue: SPR-9724
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.
As a result of the refactoring, the AsyncContext dispatch mechanism is
used much more centrally. Effectively every asynchronously processed
request involves one initial (container) thread, a second thread to
produce the handler return value asynchronously, and a third thread
as a result of a dispatch back to the container to resume processing
of the asynchronous resuilt.
Other updates include the addition of a MockAsyncContext and support
of related request method in the test packages of spring-web and
spring-webmvc. Also an upgrade of a Jetty test dependency required
to make tests pass.
Issue: SPR-9433
Currently the getNamedDispatcher(String) method of MockServletContext
always returns null. This poses a problem in certain testing scenarios
since one would always expect at least a default Servlet to be present.
This is specifically important for web application tests that involve
the DefaultServletHttpRequestHandler which attempts to forward to the
default Servlet after retrieving it by name. Furthermore, there is no
way to register a named RequestDispatcher with the MockServletContext.
This commit addresses these issues by introducing the following in
MockServletContext.
- a new defaultServletName property for configuring the name of the
default Servlet, which defaults to "default"
- named RequestDispatchers can be registered and unregistered
- a MockRequestDispatcher is registered for the "default" Servlet
automatically in the constructor
- when the defaultServletName property is set to a new value the
the current default RequestDispatcher is unregistered and replaced
with a MockRequestDispatcher for the new defaultServletName
Issue: SPR-9587
Juergen Hoeller
Nick Williams
Oliver Gierke
Phillip Webb
Sam Brannen
Chris Beams
Rob Winch
Rossen Stoyanchev