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
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
We make Liquibase aware of our custom Commons Logging-based logger by
adding its package to the Liquibase ServiceLocator’s packages to scan.
Previously, this was happening too late so Liquibase may have already
initialized and cached a particular logger.
This commit moves the registration of the extra package from the
Liquibase auto-configuration to the application listener that customises
Liquibase’s ServiceLocator. This ensures that the package is added
before Liquibase is used. Unfortunately, configuring Liquibase’s
ServiceLocator and its packages to scan causes it to try to perform
some logging, resulting in it caching the wrong type of logger. We
work around this problem by resetting Liquibase’s LogFactory once we’ve
finished setting everything up.
Closes gh-6713
Previously, RandomAccessDataFile used a semaphore and acquired it
interruptibly. This meant that an interrupted thread was unable to
access the file. Notably, this would prevent LaunchedURLClassLoader from
loading classes or resources on an interrupted thread.
The previous commit (937f857) updates RandomAccessDataFile to acquire
the semaphore uninterruptibly. This commit adds a test to
LaunchedURLClassLoader to verify that it can now load a resource from
an interrupted thread.
Closes gh-6683
Previously, auto-configuration of the Flyway and Liquibase endpoints
would fail if there were multiple Flyway or Spring Liquibase beans
in the application context.
This commit updates them so that they are now conditional on a single
candidate.
Closes gh-6609
Builds use the '-q' flag to suppress most output due to a limit of 4MB
of logs on Travis CI. However, Travis will also abort builds that
don't generate any output for 10 minutes. Thus we also use the
'travis_wait' function to make sure builds aren't aborted for up to
30 minutes.
Fixes gh-6621
Closes gh-6623
The unpack location is (largely) an implementation detail and the
Repackage Mojo was the only place where it was explicity documented.
Rather than updating the outdated location, this commit removes it
entirely to avoid encouraging people to rely on the location.
Closes gh-6624
Call afterPropertiesSet on the delegate `ResourceHttpRequestHandler`
to prevent an NPE. This change is required for compatibility with
Spring Framework 4.3 following SPR-13834.
Closes gh-6592
Previously, a NullPointerException would occur if
endpoints.docs.curies.enabled was true and the default value was being
used for either server.port or management.port.
EndpointWebMvcHypermediaManagementContextConfiguration has been
restructured to ensure that the DocsMvcEndpoint bean is defined before
the condition on its existence is evaluated. Previously this was
dependant on the class’s bean methods being processed in a particular
ordering, something that would be ok when using ASM but would vary when
using reflection.
Closes gh-6584
Update PropertiesConfigurationFactory so that collections can grow
beyond 256 items. Prior to this commit configuration property binding
used the default `DataBinder.autoGrowNestedPaths` setting of 256.
Fixes gh-6436
Update Log4J2LoggingSystem so that the FILTER is applied to the main
configuration and not to the root logger. Prior to this commit calls
to `logger.isErrorEnabled()` would not consider the filter and hence
would always return `true`. This caused `SpringApplication` to silently
swallow exceptions.
Fixes gh-5271
Previously, one SpringApplicationAdminMXBeanRegistrar was created
per context. When there was more then one context this would result
in a javax.management.InstanceAlreadyExistsException being thrown
as an attempt was made to register the MBean more than once.
This commit updates SpringApplicationAdminJmxAutoConfiguration so
that the registrar is only created when there's no such existing bean
in the context hierarchy.
Closes gh-6378
Previously, if there was a hierarchy of SpringApplications, the admin
MBean would report that the application was ready as soon as any
application in the hierarchy was ready. This could lead to a client
trying to query a property in the environment before it's available.
This commit updates the MBean registrar to that the MBean only reports
that the application is ready when the context that contains the
registrar has refreshed and fired its ApplicationReadyEvent.
Closes gh-6362
Previously, the shutdown endpoint would spawn a new thread to perform
the shutdown but did not explicitly configure its thread context
class loader (TCCL). This mean that the new thread would use the
request thread's TCCL as its TCCL. This meant that a different TCCL
would be used compared to a shutdown triggered by the shutdown hook
and also caused problems with Tomcat's thread leak detection logic.
This commit updates the shutdown endpoint to explicitly configure the
TCCL of the shutdown thread to be the ClassLoader that loaded the
endpoint's class.
Closes gh-6361
