This commit introduces transactional integration tests executing
against both JUnit and TestNG in the TestContext framework (TCF) using
@TransactionAttribute in EJBs instead of Spring’s @Transactional
annotation.
These tests disprove the claims raised in SPR-6132 by demonstrating that
transaction support in the TCF works as expected when a transactional
EJB method that is configured with TransactionAttribute.REQUIRES_NEW is
invoked. Specifically:
- The transaction managed by the TCF is suspended while such an EJB
method is invoked.
- Any work performed within the new transaction for the EJB method is
committed after the method invocation completes.
- The transaction managed by the TCF is resumed and subsequently
either rolled back or committed as necessary based on the
configuration of @Rollback and @TransactionConfiguration.
The configuration for the JUnit-based tests is straightforward and self
explanatory; however, the configuration for the TestNG tests is less
intuitive.
In order for the TCF to function properly, the developer must ensure
that test methods within a given TestNG test (whether defined locally,
in a superclass, or somewhere else in the suite) are executed in the
proper order. In a stand-alone test class this is straightforward;
however, in a test class hierarchy (or test suite) with dependent
methods, it is necessary to configure TestNG so that all methods within
an individual test are executed in isolation from test methods in other
tests. This can be achieved by configuring a test class to run in its
own uniquely identified suite (e.g., by annotating each concrete
TestNG-based test class with @Test(suiteName = "< Some Unique Suite
Name >")).
For example, without specifying a unique suite name for the TestNG
tests introduced in this commit, test methods will be executed in the
following (incorrect) order:
- CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
- CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
- RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
- RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
- CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
The reason for this ordering is that test2IncrementCount1() depends on
test1InitialState(); however, the intention of the developer is that
the tests for an individual test class are independent of those in
other test classes. So by specifying unique suite names for each test
class, the following (correct) ordering is achieved:
- RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
- RollbackForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
- RollbackForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
- CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
- CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
- CommitForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
- RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
- RollbackForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
- RollbackForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
- CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
- CommitForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
- CommitForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
See the JIRA issue for more detailed log output.
Furthermore, @DirtiesContext(classMode = ClassMode.AFTER_CLASS) has
been used in both the JUnit and TestNG tests introduced in this commit
in order to ensure that the in-memory database is reinitialized between
each test class.
Issue: SPR-6132
Prior to this commit TestNG tests would only be executed by the Gradle
build if they were located in the “testng” package. Tests in subpackages
would therefore be omitted from the build.
This commit ensures that all TestNG classes in the “testng” package and
any of its subpackages are executed in the Gradle build.
Furthermore, this commit ensures that the JUnit-based
FailingBeforeAndAfterMethodsTests test class is executed along with the
other JUnit tests even though it resides under the “testng” package.
Issue: SPR-11338
This commit adds an XML namespace equivalent of @EnableWebSocket and
@EnableWebSocketMessageBroker. Those are <websocket:handlers> and
<websocket:message-broker> respectively.
Examples can be found in the test suite.
This commit also alters the way MessageHandler's subscribe to their
respective MessageChannel's of interest. Rather than performing the
subscriptions in configuration code, the message channels are now
passed into MessageHandler's so they can subscribe themselves on
startup.
Issue: SPR-11063
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
Before this change spring-messaging contained a few WebSocket-related
classes including WebSocket sub-protocol support for STOMP as well
as @EnableWebSocketMessageBroker and related configuration classes.
After this change those classes are located in the spring-websocket
module under org.springframework.web.socket.messaging.
This means the following classes in application configuration must
have their packages updated:
org.springframework.web.socket.messaging.config.EnableWebSocketMessageBroker
org.springframework.web.socket.messaging.config.StompEndpointRegistry
org.springframework.web.socket.messaging.config.WebSocketMessageBrokerConfigurer
MessageBrokerConfigurer has been renamed to MessageBrokerRegistry and
is also located in the above package.
As of Gradle 1.8, ‘testReport true’ is deprecated. Thus in order to
generate TestNG reports alongside JUnit reports with Gradle 2.0 and
beyond, we are now using:
getReports().getHtml().setEnabled(true)
Generate docbook xml from the asciidoc reference guide and use the
docbook-reference-plugin to generate HTML (single and multi-page) and
PDF documentation.
Issue: SPR-11096
- add WebSocketHttpHeaders
- client-side support for WebSocket extensions
- DefaultHandshakeHandler updates
- replace use of ServletAttributes in JettyRequestUpgradeStratey
- upgrade spring-web to jetty 9.0.5
The key contract is MvcUrls. An instance is automatically created with
the Spring MVC namespace and the MVC Java config but can also be easily
created in any configuration.
Some example tests can be found in DefaultMvcUrlsTests.
Issue: SPR-10665, SPR-8826
MvcUriComponentsBuilder allows creating URIs that point to Spring MVC
controller methods annotated with @RequestMapping. It builds them by
exposing a mock method invocation API similar to Mockito, records the
method invocations and thus builds up the URI by inspecting the mapping
annotations and the parameters handed into the method invocations.
Introduced a new SPI UriComponentsContributor that should be implemented
by HandlerMethodArgumentResolvers that actually contribute path segments
or query parameters to a URI. While the newly introduced
MvcUriComponentsBuilder looks up those UriComponentsContributor instances
from the MVC configuration.
The MvcUriComponentsBuilderFactory (name to be discussed - MvcUris maybe?)
prevents the multiple lookups by keeping the UriComponentsBuilder
instances in an instance variable. So an instance of the factory could
be exposed as Spring bean or through a HandlerMethodArgumentResolver to
be injected into Controller methods.
Issue: SPR-10665, SPR-8826
This version fixed bugs and improved performance.
New features: "select multiple attributes" and
"Array operations and slicing improved" (a new example
has been added in tests to reflect that).
See https://github.com/jayway/JsonPath/blob/master/README
Issue: SPR-10990
This change upgrades reactor to 1.0 RC1 and also removes the
reactor-based message channel in favor of the one available from
org.projectreactor:reactor-spring.
Unfortunately, the JCache API changed quite a bit since 0.6. We're building against a snapshot of JCache 0.11 now, tracking its way to final after the Public Review Ballot.