Closes gh-6956

See gh-6956

See gh-6956

Closes gh-6936

Closes gh-6935

Closes gh-6934

Closes gh-6933

Closes gh-6932

Closes gh-6931

Closes gh-6930

Closes gh-6929

Closes gh-6910

This is an alternative to the fix made in 3b52909f which removed the
chown call entirely.

Prior to 3b52909f, the ownership of $PID_FOLDER was always changed even
when its value was /var/run. This was problematic as it could prevent
other services from creating their pid folder or file.

When a sub-folder is used, changing its ownership so that it’s owned by
the user that will run the app is desirable as it limits access to the
folder. Rather than removing the chown call entirely, this commit
ensures that it only happens when a sub-folder is being used to hold the
pid file.

Closes gh-6532

Closes gh-6914 (I hope)

Update the launch script so that it no longer changes ownership of the
PID_FOLDER.

Commit b24e736c had changed the chown
line from:
	chown "$run_user" "$PID_FOLDER/${identity}"
to:
	chown "$run_user" "$PID_FOLDER"

This meant that it was possible for the launch script to change
ownership of `/var/run` and prevent later processes from writing to
the folder.

Since PID_FOLDER is created before the chown statement, and that
the `checkPermissions` function runs to ensure that the PID file can
be written, it appears that the chown is not even required.

Fixes gh-6532

Add `spring.mvc.formcontent.putfilter.enabled` property to allow the
HttpPutFormContentFilter to be disabled.

Fixes gh-6519

Update `AbstractNestedCondition` to correctly group nested conditions
on members.

Fixes gh-6672

Closes gh-6835

See gh-6910

Add an explicit note that states that "spring.datasource.url" (or more
specifically "spring.datasource.class-name" that is inferred from the
former) is necessary to connect to a database. If the class-name isn't
specified, Spring Boot will attempt to auto-configure an embedded
database.

Closes gh-6907

Breaking API changes in Gradle 3.0 make it impossible to support
it reliably alongside Gradle 1 and 2 without mainintaining multiple
versions of our Gradle plugin. This commit updates the documentation
to note that Gradle 3 is not supported.

Closes gh-6880

Previously, in a war deployment, the web environment’s property sources
were initialized using the servlet context after the application’s
configuration had been read by ConfigFileApplicationListener. This
meant that spring.config.location configured via the servlet context
had no effect.

This commit adds a new ApplicationListener,
ServletContextApplicationListener, that initialises the configurable
web environment’s property sources using the servlet context. It’s
ordered with higher precedence than ConfigFileApplicationListener to
ensure that any properties defined in the servlet context are available
when loading the application’s configuration.

Closes gh-6801

See gh-6869

This commit improves the JMS health indicator to identify a broken broker
that uses failover. An attempt to start the connection is a good way to
make sure that it is effectively available.

Closes gh-6818

* pr/6847:
  Trace endpoint defaults to 100

Closes gh-6847

* pr/6815:
  Polish `HealthEndpoint` javadoc

Closes gh-6815

* gh-6759:
  Polish “Avoid null handler package in JarFile protocol handler registration”
  Avoid null handler package in JarFile protocol handler registration

See gh-6759

Closes gh-6759

Closes gh-6762

Closes gh-6778

So far, one has to set the "fork" value to both the start and stop
goals. Since they have the same name, sharing them in a global
configuration element does the trick. However, the plugin also supports
auto-detection of the fork value according to other parameters:
typically if an agent or jvm arguments are set, forking will be
automatically enabled. This is a problem since the stop goal is not aware
of that.

This commit transmits the value in a property attached to the
`MavenProject`. That way, the stop goal can retrieve that value and
apply the same defaults. This has the side effect that specifying the
fork value isn't necessary anymore.

Closes gh-6747

Closes gh-6559

Previously, BeanTypeRegistry did not correctly determine the type
that would be created by a factory bean if that factory bean was
returned from a bean method with arguments on a configuration class
found via component scanning.

The key difference is that bean definitions for bean methods on
configuration classes found via component scanning use ASM-based
metadata rather than reflection-based metadata. The ASM-based method
data does not provide direct access to the Method that will create the
bean. In this case, BeanTypeRegistry was falling back to looking for
a method with the matching name and no arguments. Therefore, if
the bean method had any arguments it would fail to find the method
and would, therefore, be unable to determine the type of bean
produced by the factory bean.

This commit updates BeanTypeRegistry to use logic that is very similar
to Spring Framework's ConstructorResolver's
resolveFactoryMethodIfPossible method to locate the method that will
produce the factory bean. It looks for a single method with
the required name with any number of arguments. If it finds multiple
methods with the required name and different arguments it returns
null, just as ConstructorResolver does.

Closes gh-6755