See gh-5330

Closes gh-2893

* pr/6184:
  Fix relaxed binding of SI JMX config

Instead of using an expression for JMX-related properties, this commit
properly honors relaxed binding.

Closes gh-6184

Previously, if the `contextPath` of the application wasn't the root, the
HAL browser could not initialize since the `entryPoint` was referring to
an invalid location.

This commit makes sure to take the `contextPath` into account.

Closes gh-5814

Previously, SimpleInMemoryRepository used a ConcurrentReferenceHashMap
to store its locks. The type of map will discard its entries when the
JVM comes under GC pressure. With the code in its previous form, this
could lead to a NullPointerException when the following occurred:

1. putIfAbsent returned null indicating that a new entry has been added
   to the map
2. GC pressure caused the map to discard the new entry
3. get returned null as the entry has been discard

There are two problems with the existing code:

1. Its usage of a ConcurrentMap is incorrect. The correct usage is:
   a. Call get to see if the map already contains a lock
   b. If the lock is null, create a new one
   c. Call putIfAbsent to add the new lock
   d. If the return value is non-null, another thread has created the
      lock and it should be used. If the return value is null, use the
      new lock created in b.
2. Once the use of ConcurrentMap has been corrected, the fact that it is
   a ConcurrentReferenceHashMap means that different threads could
   access the same value using different locks. This would occur if one
   thread has retrieved a lock from the map and is using it, while GC
   causes the lock to be removed from the map. Another thread then
   attempts to get the lock and, as GC pressure has remove it, a new
   lock is created allowing concurrent access to the same value.

This commit updates the code to use the ConcurrentMap correctly and also
replaces the ConcurrentReferenceHashMap with a ConcurrentHashMap. This
means that the repository will now use slightly more memory but this is
outweighed by the benefits of thread-safe updates and no risk of an NPE.

Closes gh-6115

DevTools deliberately throws an uncaught exception on the main thread
as a safe way of causing it to stop processing. This exception is
caught and swallowed by an uncaught exception handler. Unfortunately,
this has the unwanted side-effect of causing the JVM to exit with 1
once all running threads are daemons.

Normally, this isn't a problem. Non-daemon threads, such as those
started by an embedded servlet container, will keep the JVM alive and
restarts of the application context will occur when the user makes to
their application. However, if the user adds DevTools to an
application that doesn't start any non-daemon threads, i.e. it starts,
runs, and then exits, it will exit with 1. This causes both
bootRun in Gradle and spring-boot:run in Maven to report that the
build has failed. While there's no benefit to using DevTools with an
application that behaves in this way, the side-effect of causing the
JVM to exit with 1 is unwanted.

This commit address the problem by updating the uncaught exception
handler to call System.exit(0) if the JVM is going to exit as a
result of the uncaught exception causing the main thread to die. In
other words, if the main thread was the only non-daemon thread, its
death as a result of the uncaught exception will now cause the JVM
to exit with 1 rather than 0. If there are other non-daemon threads
that will keep the JVM alive, the behaviour is unchanged.

Closes gh-5968

Closes gh-5653

Closes gh-6172

Closes gh-5971

Closes gh-5956

Closes gh-6160

Closes gh-6165

In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.

Fixes gh-5986

* 1.3.x-liquibase-endpoint:
  Close connection after use in LiquibaseEndpoint

Update LiquibaseEndpoint so that connections are closed and returned to
the pool after use.

Fixes gh-6118

Update SpringApplicationBuilder so that properties of the form
`abc=d:e:f` are correctly parsed. Prior to this commit the `:` delimiter
would always be chosen over `=`, even if `=` occurred first.

Fixes gh-6121

Update TypeUtils to guard against the use of older Java versions.
Both `Collection` and `Map` type lookups now fallback to generic free
versions of the classes.

Prior to this commit using `xmlbeans-maven-plugin` in combination with
Spring Boot's annotation processor could result in
`IllegalArgumentException: Incorrect number of type arguments`.

Fixes gh-6122

Update BeanDefinitionLoader to support loading from package names that
do not contain dots.

Prior to this commit `new BeanDefinitionLoader(registry, "somepackage")`
would fail because "somepackage" exists and is a resource but does not
contain valid XML. Somewhat surprisingly the InputStream returned by
the resource actually contains the listing of files in the package.

Fixes gh-6126

Update BasicJsonParser to fix potential exceptions if strings happen
to be empty.

Fixes gh-6136

* pr/6125:
  Update DataSourceBuilder aliases

This commit adds a `user` alias for the `username` property which permits
the use of `OracleDataSource`.

Closes gh-6124, gh-6027, gh-6125

Closes gh-6105

* gh-6056:
  Check factory method metadata to avoid NPE in devtools condition

Closes gh-6056

- Limit shared state between FileSystemWatcher and the watching thread
- Use a private monitor rather than synchronizing on this
- Use a Runnable implementation rather than subclassing Thread
- Synchronize consistently when reading and writing state

Closes gh-6039

Previously, JarURLConnection didn't override getPermission(). This
meant that it required all permissions. This was at odds with the
Oracle JVM's concrete sun.net.www.protocol.jar.JarURLConnection which
overrides getPermission to return a FilePermission with the read
action for the path of the underlying jar.

This commit updates our JarURLConnection to align its behaviour with
sun.net.www.protocol.jar.JarURLConnection.

Closes gh-5411

This reverts commit 66e093ed. There's
a regression [1] in Tomcat 8.0.35 that causes it to throw an NPE when
it scans a jar file without a manifest. It's already been fixed [2].

See gh-6087

[1] https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?annotate=1742274#l369
[2] https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?annotate=1744197#l369

Closes gh-6090

Closes gh-6089

Closes gh-6088

Closes gh-6087

Closes gh-6086

Closes gh-6085

Closes gh-6033

The list of changes is written to on one thread and read from on
another. Without some form of sychronization this is not thread-safe.

This commit makes changes a synchronized list which should guarantee
that the reading thread can see the changes made by the writing thread.
It also removes a redundant call to clear the list of changes at the
start of waitsForPollingInterval.

See gh-6038