* pr/5511:
Polish contribution
Upgrade elasticsearch to 2.2.0
Polish contribution
Deprecate Undertow container's constructors that have a port parameter
Remove unused unsatisfiedDependency.getInjectionPoint() call
Polish contribution
Allow Tomcat's minimum threads to be configured via the environment
The changes made in a6c1668b mean that the web starter no longer
depends on spring-boot-starter-validation. Instead, it depends
directly on hibernate-validator. This means that the exclusion of the
validation starter in the TomEE deployment test app no longer matches
anything and hibernate-validator is packaged in the war. This breaks
the application as TomEE ships with Bean Validation 2.0 and the
version of Hibernate Validator being used requires 2.1.
This commit updates the exclusions in the TomEE deployment app so that
hibernate-validator is excluded once again. This allows the app to
use TomEE's bundled Bean Validation implementation.
The stale spring-boot-starter-validation exclusion has been removed
from the Wildfly deployment test app. It is redundant as Wildfly ships
with Bean Validation 2.1. This brings this test app into line with
the Glassfish test app.
Closes gh-5454
This commit introduces a new annotation, @AutoConfigureRestDocs,
which can be used to enable auto-configuration of Spring REST Docs.
The auto-configuration removes the need to use Spring REST Docs' JUnit
rule and will automatically configure MockMvc. Combined with the new
auto-configuration for MockMvc it allows a test class to be free of
boilerplate configuration:
@RunWith(SpringRunner.class)
@WebMvcTest
@AutoConfigureRestDocs(outputDir = "target/generated-snippets",
uriScheme = "https", uriHost = "api.example.com",
uriPort = 443)
public class ExampleDocumentationTests {
@Autowired
private MockMvc mvc;
@Test
public void documentIndex() {
// …
}
}
For more advanced customization a RestDocsMockMvcConfigurationCustomizer
bean can be used.
If a RestDocumentationResultHandler is found in the context, it will
be passed to the ConfigurableMockMvcBuilder's alwaysDo method as part
of its customization.
Closes gh-5563
In particular it now accepts a list of maps containing
"authority" keys (which is what you get from a standard JSON
decoding of a Spring Security Authentication).
Fixes gh-5482
In the web starter we shouldn't depend explicitly on any EL
implementation, otherwise when people build wars and deploy
them in containers that have their own EL there is a conflict.
We can still depend on hibernate-validator to support
JSR-303 in web apps because the EL implementation comes with
the container.
Fixes gh-5454
Rework the new testing support so that @SpringApplicationTest can be
used for standard integration tests, web integration tests with a
mock Servlet environment and web integration tests with an embedded
servlet container. This means that it a replacement for 1.3's
@IntegrationTest and @WebIntegrationTest and allows all
SpringApplication testing to be configured using a common annotation.
The old @IntegrationTest and @WebIntegrationTest along with their
supporting classes have been reinstated to their previous form (while
remaining deprecated). This should ensure that they continue to work
in 1.4 exactly as they did in 1.3 giving users a smooth path to
@SpringApplicationTest.
See gh-5477
Previously, if loader.path directly specified a jar file that contained
nested archives (.zip or .jar), launching would fail unless those
nested archives were uncompressed. However, if loader.path specified a
directory that contained such a jar file the launch would succeed. This
was because the nested archives within the jar were ignored.
This commit updates PropertiesLauncher so that its behaviour in the
scenarios described above is consistent by not looking for archives
nested with a jar that’s be specified on loader.path. The javadoc for
loader.path has also been updated to make it clear that loader.path
can points to directories or jar files, bringing it into line with
the reference guide.
Closes gh-3701
Following changes to LaunchedURLClassLoader made in 87fe0b2a, it is
no longer necessary for the launcher to load MainMethodRunner via
reflection as both the app class loader that the launcher URL class
loader share the same MainMethodRunner class.
This commit takes advantage of this by updating Launcher to instantiate
MainMethodRunner directly rather than via reflection, removing one
source of possible exceptions in the launcher.
As the MainMethodRunner is now loaded directly and its class is shared
between the two class loaders, there’s no longer a need for it to
implement Runnable. This allows it to throw Exception from its run
method, rather than having to wrap any Exception in a RuntimeException.
Lastly, rather than catching any exception thrown from the launch,
Launcher and its subclasses have been updated to allow this exception
to be thrown from the main method. This allows the Exception to reach
the JVM, to be processed by our registered uncaught exception handler,
and to trigger the JVM’s standard processing for exiting due to a
failure. This removes the need for the Launcher itself to call
System.exit(1) and ensures that the exception is only output to the
console if it hasn’t been registered as a logged exception.
Closes gh-5358
Stephane Nicoll
John Blum
Huang YunKun
Andy Wilkinson
dreis
Johnny Lim
Quinten De Swaef
Igor Stepanov
Phillip Webb
Dave Syer
Brendan Kirby
Kazuki Shimizu