1. 19 Feb, 2016 12 commits
    • Andy Wilkinson's avatar
      Merge pull request #4823 from Pedro Costa · 59e119eb
      Andy Wilkinson authored
      * gh-4823:
        Polish contribution
        Make TLS protocols and cipher suites configurable via the environemnt
      59e119eb
    • Andy Wilkinson's avatar
      Polish contribution · 742df6b6
      Andy Wilkinson authored
      Rename the new property to enabledProtocols to align more closely with
      Undertow and Tomcat’s underlying configuration setting.
      
      Closes gh-2109
      742df6b6
    • Pedro Costa's avatar
      766ccd75
    • Andy Wilkinson's avatar
      Upgrade to Spring Session 1.1.0.RC1 · 7512687c
      Andy Wilkinson authored
      Closes gh-5161
      7512687c
    • Andy Wilkinson's avatar
    • Andy Wilkinson's avatar
      Provide better diagnostics when an application fails to start · df6c2041
      Andy Wilkinson authored
      This commit introduces a new failure analysis mechanism that can be
      used to provide diagnostics to a user when their application fails
      to start.
      
      When application context refresh fails. FailureAnalyzer
      implementations are loaded via spring.factories. The analyzers are
      called in order, with the first non-null analysis of the failure
      being used. The analysis is reported to the use by
      FailureAnalysisReporters which are also loaded via spring.factories.
      
      A single FailureAnalysisReporter is provided out of the box. It logs
      an error message with details of the analysis, providing the user
      with a description of the failure and, if available, some actions
      that they may be able to take to resolve the problem without also
      displaying a stack trace that is of little value.
      
      Two analysers are provided initially. One for an embedded servlet
      container port clash and another for BeanCurrentlyInCreationExceptions.
      More analysers are planned (for UnsatisfiedDependencyException and for
      NoUniqueBeanDefinitionException) once some updates have been made
      to Spring Framework to make those failures more amenable to analysis.
      
      Closes gh-4907
      df6c2041
    • Andy Wilkinson's avatar
      d4548967
    • Andy Wilkinson's avatar
      Update Ant support following changes the executable jar layout · fcbf15ae
      Andy Wilkinson authored
      Closes gh-4897
      fcbf15ae
    • Andy Wilkinson's avatar
      Use a conventional delegation model in LaunchedURLClassLoader · 87fe0b2a
      Andy Wilkinson authored
      When an application is run as an executable archive with nested jars,
      the application's own classes need to be able to load classes from
      within the nested jars. This means that the application's classes need
      to be loaded by the same class loader as is used for the nested jars.
      When an application is launched with java -jar the contents of the
      jar are on the class path of the app class loader, which is the
      parent of the LaunchedURLClassLoader that is used to load classes
      from within the nested jars. If the root of the jar includes the
      application's classes, they would be loaded by the app class loader
      and, therefore, would not be able to load classes from within the
      nested jars.
      
      Previously, this problem was resolved by LaunchedURLClassLoader being
      created with a copy of all of the app class laoder's URLs and by
      using an unconventional delegation model that caused it to skip its
      parent (the app class loader) and jump straight to its root class
      loader. This ensured that the LaunchedURLClassLoader would load both
      the application's own classes and those from within any nested jars.
      Unfortunately, this unusual delegation model has proved to be
      problematic. We have seen and worked around some problems with Java
      Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
      that cannot be made to work with the current delegation model.
      
      This commit reworks LaunchedURLClassLoader to use a conventional
      delegate model with the app class loader as its parent. With this
      change in place, the application's own classes need to be hidden
      from the app class loader via some other means. This is now achieved
      by packaging application classes in BOOT-INF/classes (and, for
      symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
      JarLauncher and the PropertiesLauncher (which supports the executable
      jar layout) have been updated to look for classes and nested jars in
      these new locations.
      
      Closes gh-4897
      Fixes gh-4868
      87fe0b2a
    • Andy Wilkinson's avatar
      Improve JDBC driver dependency management and class name test coverage · 9be69f1a
      Andy Wilkinson authored
      Previously, the DatabaseDriver enumeration contained entries for
      some databases without having dependency management for the database
      driver dependency. This leads to the possibility of a user inadvertently
      using the wrong version of a driver where the class names do not match
      those listed in the enumeration. A further problem is that we do not
      test that the class names listed in the enumeration match the
      names of Driver and XADataSource implementations in the database driver.
      
      This commit completes the database driver dependency management so that
      dependency management is provided for every driver that is both listed
      in DatabaseDriver and available in Maven Central. It also adds tests
      for DatabaseDriver that ensures that each class that is listed exists
      and implements the required interface (java.sql.Driver or
      javax.sql.XADataSource).
      
      Closes gh-4946
      9be69f1a
    • Andy Wilkinson's avatar
      Set main thread's context class loader when starting Tomcat · ff99bb07
      Andy Wilkinson authored
      When an app is deployed to Tomcat, all of the application's startup
      is performed with a WebAppClassLoader being the thread context
      class loader. When an app is using embedded Tomcat, the
      WebAppClassLoader is created as part of the application starting but
      is never set as the thread context class loader. This difference
      in TCCL can cause problems. For example, it breaks the use of JNDI
      during application startup with embedded Tomcat.
      
      This commit updates the embedded Tomcat servlet container to set
      the TCCL to be the WebAppClassLoader once the Tomcat context has
      been started. Once Tomcat is stopped, it sets the TCCL back to the
      ClassLoader that loaded it.
      
      Closes gh-2308
      ff99bb07
    • Andy Wilkinson's avatar
      Use @DirtiesContext to avoid unwanted context caching in the tests · d6e0b5a1
      Andy Wilkinson authored
      We rarely use the same configuration in multiple test classes, but
      Spring’s Test framework caches each context by default. For projects
      with large numbers of integration tests, this can lead to tens of
      contexts being cached. This increases memory usage, live thread count,
      etc for no benefit.
      
      This commit adds @DirtiesContext to the integration tests in
      spring-boot, spring-boot-autoconfigure, and spring-boot-actuator so
      that the context is closed once the test class has completed.
      
      See gh-5141
      d6e0b5a1
  2. 18 Feb, 2016 10 commits
  3. 17 Feb, 2016 6 commits
  4. 16 Feb, 2016 12 commits