Previously, the project version was used while filtering the apps
source during syncing but it was not considered as an input to
the task. This could result in the syncing being skipped even though
the project's version had changed.
This commit introduces a new custom task to make the configuration
more declarative and to allow the necessary input configuration to be
done in a single place.
Closes gh-28197
An upgrade to Apache Commons Compress allows the build plugins to write
the launch script to the fat jar as a proper preamble, making the file
compatible with more jar and zip tooling.
Fixes gh-22336
Change the order of `DataSourceScriptDatabaseInitializerDetector` so
that it always runs last. This update allows script initialization to
be combined with a high-level migration tool such as Flyway.
Closes gh-26692
This commit reworks the initial proposal so that jobs and triggers are
treated as first class concepts.
`/actuator/quartz` now returns the group names for jobs and triggers.
`actuator/quartz/jobs` returns the job names, keyed by the available
group names, while `/actuator/quartz/triggers` does the same for
triggers.
`/actuator/jobs/{groupName}` provides an overview of a job group. It
provides a map of job names with the class name of the job.
implementation
`/actuator/triggers/{groupName}` provides an overview of a trigger
group. There are five supported trigger implementations: cron, simple,
daily time interval, calendar interval, and custom for any other
implementation. Given that each implementation has specific settings,
triggers are split in five objects.
`/actuator/jobs/{groupName}/{jobName}` provides the full details of a
particular job. This includes a sanitized data map and a list of
triggers ordered by next fire time.
`/actuator/triggers/{groupName}/{triggerName}` provides the full details
of a particular trigger. This includes the state, its type, and a
dedicate object containing implementation-specific settings.
See gh-10364
Deprecate the `Bootstrapper` interface entirely and provide a
`BootstrapRegistryInitializer` alternative so that people can migrate.
Unfortunately our previous attempt to fix the typo in the `Bootstrapper`
interface didn't provide us a way to remove the deprecated method
without impacting users. It was also problematic for people who were
implementing `Bootstrapper` rather than using a lambda since they needed
to introduce the deprecated method.
We unfortunately can't see a way to fix the original typo without
introducing a new interface.
Fixes gh-25735
userDefinedMappingsSecureByDefault in
SampleSessionWebFluxApplicationTests may fail with an NPE if the
session times out before the initial response is sent due to the absence
of a SESSION cookie in the response. The test uses a short session
timeout (2 seconds) and we've seen the problem occur on CI when,
presumably, a noisy neighbour has caused some CPU starvation.
This commit increases the timeout to 5 seconds to reduce the chance of
a short period of CPU starvation causing the test to fail.
Closes gh-25572
Previously, actuator endpoints were registered with Jersey upon
injection of the ResourceConfig bean into a registrar class rather than
using a ResourceConfigCustomizer. This was done to fix a problem
when running the Actuator on a separate port where the main application
context's customizers were also applied to the management context,
breaking the singleton contract for those resources. This approach
meant that the registration could be performed at any point after the
ResourceConfig had been created. When Jersey's configured as a Filter
this resulted in the registration failing as the attempt was being made
after the Filter lifecyle callbacks which make the ResourceConfig
immutable.
This commit reworks the endpoint registration to be performed using a
ManagementContextResourceConfigCustomizer, a resource config customizer
that's only applied to the ResourceConfig that's used by the Actuator.
When there's a separate management context, this ResourceConfig is
created by the Actuator's auto-configuration and the management context
resource config customizers are applied to it during its creation. The
main application's customizers are not applied. When the actuator is
using the same context as the main application, this ResourceConfig is
created by the main application. In this case a
ResourceConfigCustomizer is defined that delegates to all
ManagementContextResourceConfigCustomizers, allowing them to register
the actuator endpoints with the main ResourceConfig.
Fixes gh-25262
Prior to this commit, every test started a new testcontainer. By splitting the
tests apart we can make use of static containers that are only instantiated once
per application (TomEE, Wildfly etc.)
See gh-25446
Previously, DataSource initialization was triggered via a
BeanPostProcessor or a schema created event from JPA. This caused
numerous problems with circular dependencies, bean lifecycle, etc and
added significant complexity.
This commit reworks DataSource initialization to remove the use of a
BeanPostProcessor entirely. In its place, DataSource initialization is
now driven by an InitializingBean with dependency relationships
between beans ensuring that initialization has been performed before
the DataSource is used. This aligns with the approach that's worked
well with Flyway and Liquibase.
More changes are planned to further simplify DataSource initialization.
The changes in this commit are a foundation for those changes. Any new
public API in this commit is highly likely to change before the next
GA.
Fixes gh-13042
Fixes gh-23736
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Update jar `Handler` fallback logic to directly support Tomcat
'jar:war:file' URLs. This commit allows contents to be accessed without
the JDK needing to extracted the nested jar to the temporary folder.
Closes gh-24553
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
Andy Wilkinson
Phillip Webb
dreis2211
Madhura Bhave
izeye
Scott Frederick
bono007
Stephane Nicoll
weixsun
nguyensach
Madhura Bhave
Hatef Palizgar