If the Hibernate autoconfig is not used to create an EntityManager
then I suppose it's possible that the JpaProperties might be null
when everything else is ready for the event to be published.
There's no test case because I think it's a corner case.
Fxies gh-1075
When there are parent contexts we already had a strategy for registering
the actuator endpoints, but not the regular JMX or Integration MBeans.
This chnage makes the autoconfigs for JMX aware of the parent context.
Also adds a sample with a parent context.
See gh-847
- Log to the correct class
- Set Auto-configure after Thymeleaf hint on main class instead of
internal static class
- Use 'thymeleafViewResolver' bean name instead of class for
conditional bean checks
- Fix class name in properties documentation
Fixes gh-1052
Anywhere that an MBeanServer is needed it should be
created @Conditionally, so that user can exclude the
JmxAutoConfiguration and still get the other JMX
behaviours automatically.
I decided to go with both approaches (make the autoconfig for
repositories @ConditionalOnMissingBean(RepositoryFactoryBeanSupport),
so the first one wins; and also make them conditional on
spring.data.*.repositories.enabled=true. The ordering problem
is still there really (it's not defined which repositories will
be created by the autoconfig), so if a user is going to have
2 repository implementations on the classpath, he is going to
have to either choose one to disable, or manualy @Enable* the
other one.
Fixes gh-1042
Update Spring Mobile support with the following changes:
- Apply source formatting
- User lowercase property prefixes
- Use dashed notation when accessing properties
- Inline some constants
See gh-1049
Extract common "depends on" functionality to a new
EntityManagerFactoryDependsOnPostProcessor class.
Apply consistent formatting.
Fix issue with Flyway location detection.
It was doing scary things (like starting elasticsearch, hornetq etc).
There's still an outstanding question about why the context was
not being properly closed in such a scenario (maybe one of those
embedded servers lurking on a background thread?).
See gh-1034
They all want to create an MBeanServer and when that happens
user sees no MBeans, or sometimes just one set (Spring Core,
Spring Integration or Spring Boot). To harmonise them we
create a @Bean of type MBeanServer and link to it in the
other autoconfigs
Fixes gh-1046
We now register the Jackson JodaTime module with Jackson ObjectMappers
if it is on the classpath. We also register the JSR-310 module if it's
on the classpath and the application is running Java 8 or better.
Extracted the Jackson specific configuration previously residing in
HttpMessageConvertersAutoConfiguration into a JacksonAutoConfiguration
class.
Added the Jackson JSR-310 module as a managed Boot dependency.
Added a new @ConditionalOnJava annotation that allows to conditionally
enable configuration based on the Java version that is running.
The annotation currently supports two modes of restricting Java versions:
the default mode checks for a Java version equal or better than the
requested one. Beyond that it can be configured to only match if Java
version is older than the configured one.
There were some residual issues to do with the changes to the implementation
of security.basic.enabled=false. It was a good idea to have a filetr chain
triggered by the flag being off because it smooths the way for user-defined
filter chains to use the Boot AuthenticationManager (as a first step at least),
but it wasn't a goog idea to add any actual secuity features to that filter.
E.g. if it has HSTS then even an app like Sagan that has some secure endpoints
that it manages itself and the rest is unsecured has issues because it can't
accept connections over HTTP even on unsecure endpoints.
TODO: find a way for security.ssl_enabled=true to apply to only the user-
defined security filter (maybe not possible or worth the effort, since they
can inject a SecurityProperties if they need it?).
See gh-928
This commit changes the default behavior of the HornetQ auto
configuration. Prior to this commit, an embedded broker was only
started when it was requested explicitly by a configuration option.
This is inconsistent with the ActiveMQ support and boot favors the
easiest route. If the necessary classes are available, HornetQ is
embedded in the application by default.
Fixes gh-1029
HypermediaAutoConfiguration didn't consider an @EnableHypermediaSupport
annotation being present in the user configuration which could've caused
it to be evaluated twice.
This is especially the case if both the auto-configuration for Spring
HATEOAS and Spring Data REST kick in as Spring Data REST actively declares
@EnableHypermediaSupport. The double evaluation then causes injection
ambiguities as we now get multiple beans of e.g. LinkDiscoverers deployed.
Schema initialization now happens in @PostConstruct (effectively)
whether it is via the Hibernate EntityManagerFactory or the
Boot DataSourceInitialization (in addition or instead). The data.sql
script if it exists is still executed on an event fired from the
other places, so those tests are passing.
Flyway and liquibase have bean factory post processors (like
the one they use to order the audit aspect in Spring Data) that
enforce a dependency on those components from the EntityManagerFactory.
So Hibernate validation is still happy (and there are 2 tests to
prove it now as well).
Fixes gh-1022
ElasticSearchAutoConfiguration depends on two Spring Data Elasticsearch
classes (TransportClientFactoryBean and NodeClientFactoryBean), however
it’s only conditional on Elasticsearch itself being on the classpath.
This lead to start up failures due to a ClassNotFoundException. Its
@ConditionalOnClass configuration has been updated so that the
auto-configuration will only be enabled if both Elasticsearch and Spring
Data Elasticsearch are on the classpath.
The dependencies on TransportClientFactoryBean and NodeClientFactoryBean
were ‘hidden’ in ElasticsearchProperties. The logic that uses these
types has been moved into ElasticSearchAutoConfiguration so that the
usage of the types and the related @ConditionalOnClass configuration
is in the same file.
Fixes#1023
Irritatingly a ResourceBundleMessageSource never gives up trying to
create a resource bundle for every message resolution, so to stop
it logging all those warnings (and probably sucking performance-wise)
we need to disable the MessageSource if a bundle is not provided.
Fixes gh-1019
This is *really* nasty (and led me to discover a related bug
https://jira.spring.io/browse/SPR-11844), but fortunately easy to
hide from users once you have a test case.
The problem is that Spring Security registers a `BeanPostProcessor`
to handle `GlobalAuthenticationConfigurerAdapters`, and Boot
registers a `BeanPostProcessor` to handle injecting the packages
to scan into an `EntityManagerFactory` from `@EntityScan`. The
clash comes because the `EntityScanBeanPostProcessor` wants to be
postprocessed by the Security postprocessor, but if the Security
configuration depends on JPA it won't be ready in time.
The fix (or workaround) depending on how you look at it is to
prevent the other bean post processors from taking an interest in
`EntityScanBeanPostProcessor` at all (mark it as synthetic).
Fixes gh-1008
Added 2 new spring.datasource.* properties ("data" like
"schema", and "deferDdl" like the "spring.jpa.hibernate.*"
flag). The SQL scripts are then run separately and the "data"
ones are triggered by a new DataSourceInitializedEvent,
which is also published by the Hibernate DDL schema export.
Fixes gh-1006
