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
Provide auto-configuration support for HornetQ JMS broker, along with
an additional starter POM.
The connection factory connects to a broker available on the local
machine by default. A configuration switch allows to enable an embedded
mode that starts HornetQ as part of the application.
In such a mode, the spring.hornetq.embedded.* properties provide
additional options to configure the embedded broker. In particular,
message persistence and data directory locations can be specified. It is
also possible to define the queue(s) and topic(s) to create on startup.
Fixes: gh-765
Older versions of Spring Social will not have the SocialConfigurerAdapter
so making social autoconfig conditional on that class makes sense (since it
all extends from it).
Fixes gh-986
If you bind to Map<String,Object> you get a nested Map instead
of period-separated keys. This change just makes JpaProperties
expose a Map<String,String> so the keys are sane.
Fixes gh-988
Actually the web-secure sample is misusing
security.basic.enabled=false (IMO) - it should be a flag
to say that you want to temporarily disable the basic security
fallback on application endpoins, not way to disable all
security autoconfiguration.
Added test case to web-secure sample to ensure a user
can log in.
Fixes gh-979
Restore the dependency on commons-logging (transitively via spring-core)
for spring-boot. This means that we are not tied directly to SLF4J, but
it is still an option that can be used via `jcl-over-slf4j`.
The `spring-boot-starter-parent` continues to replace `commons-logging`
with `jcl-over-slf4j`.
Fixes gh-981
Update Spring Social auto-configurations to read properties using
the `dashed` notation and with the appropriate prefixes. This allows
properties to be specified in any of the relaxed forms.
Also minor refactor to extract common logic to a new
SocialAutoConfigurerAdapter base class.
See gh-941
Boot’s auto-configuration for FreeMarker and Velocity relies on Spring’s
support for them that’s packaged in spring-context-support. Only
auto-configure them if their respective Spring classes are on the
classpath
Fixes#940
In addition I added some convenience methods to ServerProperties
(servletMapping() and servletPrefix()) for manipulating the
servlet path as provided by the user (e.g. normalizing it into
a valid Servlet mapping path for the DispatcherServlet).
Fixes gh-939, see also gh-936
In 1.0, the property spring.jpa.hibernate.namingstrategy could be
used to configure Hibernate's naming strategy. This was at odds with
most other configuration where binding to namingStrategy would require
a property with some indication that it was two separate words, for
example: naming-strategy, naming_strategy, or namingStrategy
This commit adds a new setter, setNamingstrategy, to JpaProperties so
that an app that was using namingstrategy in 1.0 continues to work
in 1.1.
Issue #928
