1. 28 3月, 2019 1 次提交
  2. 22 1月, 2014 1 次提交
    • S
      Introduce EJB-based transactional tests in the TCF · c0eafa9e
      Sam Brannen 提交于
      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
      c0eafa9e
  3. 31 1月, 2012 1 次提交
    • C
      Rename modules {org.springframework.*=>spring-*} · 02a4473c
      Chris Beams 提交于
      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
      02a4473c
  4. 19 3月, 2010 1 次提交
  5. 18 1月, 2010 1 次提交
  6. 07 11月, 2009 2 次提交