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
Previously, the documentation included hand-written tables for the
application, production, and technical starters.
This commit replaces the hand-written tables with tables that are
generated automatically from all of the starter poms, thereby ensuring
that the documentation is automatically kept up-to-date as starters
are added and removed. An extra column provided a link to each
starter's pom on GitHub has also been added to the table. This makes
it easier for users to see exactly what each starter contains.
Closes gh-5267
This commit adds a `defaultValue` attribute to the `springProperty` tag
of Logback. That attribute can be used to specify a default value.
Closes gh-5447
It was seeen that if a different plugin was used to package Spring Boot
that the project would load but no autoconfiguration actually took
place and many features were mysteriously not working. Adding a check
to ensure that some factories are always loaded as this is expected.
Closes gh-5465
Previously, the default BuildInfo task created by the DSL was called
buildInfo. Due to Gradle's lack of namespacing for tasks, this meant
there was a slight risk that it could clash with another task. It
also didn't following the naming used by Boot's run task which is
named bootRun.
This commit renames the default BuildInfo task to bootBuildInfo to
match bootRun and to hopefully avoid clashes with tasks from other
plugins.
Closes gh-5518
Previously, FindMainClassTask would look for a property named main
on any class named run. This was based on the assumption that the
run task would be a JavaExec task (typically provided by the
application plugin). If the run task was not a JavaExec task (more
accurately, if it did not have a main property) this would result in
a build failure due to trying to read a non-existent property.
This commit updates FindMainClassTask to only use the main property
of the run task if the task is a JavaExec task. This guarantees that
the property will exist on the task, and unlike using any property
named main on a task named run, also guarantee that its value will
refer to a Java class with a main method.
Closes gh-5501
This commit fixes `IntegrationAutoConfiguration` to actually rely on the
auto-configured `MBeanServer` rather than attempting to create it again.
If JMX support is disabled, no attempt to register integration-related
MBeans is made.
Closes gh-5309
Restore Spring Boot 1.3.2 behavior of re-applying system properties
when SLF4J based loggers are re-initialized. Reapplying system
properties is required when using the Spring Cloud config server since
PropertySourceBootstrapConfiguration directly calls the system
initialize method.
Fixes gh-5491
This commit polihes the original Neo4j contribution in several areas.
Rather than providing the packages to scan, this commit rearranges the
`EntityScan` and `EntityScanRegistrar` so that the logic can be shared
for other components. If no package is provided, scanning now defaults to
the "auto-configured" package(s) and a `@NodeEntityScan` annotation
allows to override that.
The configuration has also been updated to detect the driver based on the
`uri` property. If the embedded driver is available we use that by
default. If it is not available, we're trying to connect to a Neo4j
server running on localhost. It is possible to disable the embedded mode
or set the `uri` parameter explicitly to deviate from these defaults.
The sample no longer relies on the embedded driver for licensing reason:
rather it expects an instance running on localhost (like other
data-related samples) and gracefully ignore any connection error. A
README has been added in the sample to further explain the available
options;
Closes gh-5458
Andy Wilkinson
Stephane Nicoll
Johnny Lim
Phillip Webb
Gary Russell
Eddú Meléndez
Rob Baily
oEmbedler Inc
Michael Hunger