Update the jar `Handler` class to support a non-reflective fallback
mechanism when possible. The updated code attempts to capture a regular
jar URL before our handler is installed. It can then use that URL as
context when creating the a fallback URL. The JDK jar `Handler` will
be copied from the context URL to the fallback URL.
Without this commit, resolving new Tomcat URLs of the form
`jar:war:file:...` would result in an ugly "Illegal reflective access"
warning.
Fixes gh-18631
Refine the `PortInUseException` logic in `NettyWebServer` to only throw
an exception if the port is set. The prevents a misleading exception
from being thrown when a domain socket is being used.
Closes gh-24529
Update `NettyWebServer` to deal with any `UnsupportedOperationException`
thrown from `DisposableServer`. Specifically, this commit allows the
`NettyWebServer` to work with domain socket backed servers which cannot
provide a port.
Fixes gh-24529
Prior to this commit, running the bootBuildImage Gradle task on a
project configured for war packaging would result in a jar file being
built and used in the image instead of the war file. With this commit
an error will be thrown from the plugin in this case.
Fixes gh-24521
Add an overloaded `ConfigDataEnvironmentPostProcessor.applyTo` method
that accepts a listener that can used to track the updates that were
applied to the `Environment`.
The listener can be used to track the which `ConfigDataLocation` and
the `ConfigDataResource` were used to add a `PropertySource`. The lister
can also be used to tell which profiles were applied.
This enhancement is being added in a patch release because it's will
be useful for Spring Cloud 2020.0.0.
Closes gh-24504
Allow directory locations that exist but do not contribute properties
to be specified without an `optional:` prefix. This commit fixes logic
introduced in commit 3dc03ac2752 which didn't account for the fact that
a directory might contain only profile specific property files and that
profiles might not always be active.
Closes gh-24499
Update `StandardConfigDataLoader` to use unique names for property
sources imported from a wildcard location.
Prior to this commit, all the property sources created from the same
wildcard location would have the same name. Each time a property source
that is equal to an existing property source is added, it replaces the
existing property source. Property source equality is name-based so this
resulted in the last property sources from the wildcard location
winning.
This commit updates `StandardConfigDataLoader` to use the resolved
Resource rather than the wildcard location in which it was discovered
in the name of the property source that it creates, ensuring that each
is property source from a wildcard location is uniquely named.
Fixes gh-24428