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, 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
Commit 3ea84f9e1 has wrongly introduced a `@Primary` marker on
`IntegrationMBeanExporter` so any use of both Spring's JMX support
and Spring Integration's JMX support leads to an exception. This commit
makes sure to remove the unnecessary `@Primary`
Closes gh-6328
This commit makes sure that the condition that links a `MongoClient` to
the embedded mongo server kicks in only if `MongoClientFactoryBean` is
also on the classpath.
Previously, only a condition on the mongo driver existed, leading to
`ClassNotFoundException` if Spring Data MongoDB wasn't available.
See gh-6203
The name of a JOOQ SQLDialect does not always match the name defined
in sql-error-codes.xml. For example, the Postgres translator was not
initialized correctly because in JOOQ the dialect is named
SQLDialect.POSTGRES, but in sql-error-codes.xml the bean is named
"PostgreSQL".
This commit updates the translator to use the dialects third-party
springDbName which ensures that it maps correctly to the entries in
sql-error-codes.xml.
Closes gh-5884
While working on gh-5309, a regression was introduced and fixed right the
way on master. Unfortunately, the fix wasn't applied to `1.3.x` as it
should have been.
This commit applies 6dd8415 to `1.3.x`
Closes gh-5901
ErrorMvcAutoConfiguration creates a BeanNameViewResolver bean in case
the user has used @EnabledWebMvc and disabled WebMvcAutoConfiguration.
If the user hasn’t used @EnabledWebMvc, WebMvcAutoConfiguration will
creates its BeanNameViewResolver and override the one that’s already
been defined by ErrorMvcAutoConfiguration.
This commit makes WebMvcAutoConfiguration’s BeanNameViewResolver
definition conditional on there being no existing BeanNameViewResolver
bean definition.
Closes gh-5354
to stop it from being included in the enclosing @Configuration.
That way, if the app is not a web app, then there really is a
client_credentials OAuth2 resource (as claimed in the user guide).
Fixes gh-5735
Rabbit client 3.6.* uses TLSv1.1 as the default algorithm which
many brokers are deisabling these days. Spring AMQP supports
changing the algorithm by name, so this is just a pass thru for
that.
It sometimes has to catch an exception from the security filter so
it needs to be before, and somehow this hasn't been a problem up to
now, but probably only by some fluke.
Fixes gh-5792
Previously, spring.thymeleaf.cache was only applied to auto-configured
TemplateResolver. This commit also applies the propery to the
auto-configured ThymeleafViewResolver.
Closes gh-5395
Update UserInfoTokenServices.getPrincipal() so that it can be overridden
by subclasses to allow a custom authenticated principal to be returned
from the authorized request parameters.
Fixes gh-5053
Update ServerProperties so that `null` values are not applied when
customizing the EmbeddedServletContainerFactory. Primarily changed to
stop `server.undertow.accesslog.enabled` from being blindly applied.
Fixes gh-5515
This commit fixes `IntegrationAutoConfiguration` to actually rely on the
auto-configured `MBeanServer` rather than attempting to create it again.
If JMX support is disabled, no attempt to register integration-related
MBeans is made.
Closes gh-5309
This commit prevents the Artemis embedded mode to kick-in if the
`EmbeddedJMS` class it not in the classpath. The previous condition would
match if only `artemis-server` was on the classpath while
`artemis-jms-server` is actually required.
Closes gh-5452
Spring Buildmaster
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Nasko Vasilev
Julien May
Artem Bilan
Vedran Pavic
tfeiner
Dave Syer
Venil Noronha
Sergey Pauk