Previously, EnableAutoConfigurationImportSelector assumed that it
would always find auto-configuration attributes from an
@EnableAutoConfiguration annotation. This assumption does not hold
true in certain circumstances, although exactly what those
circumstances are is unclear. It could occur if the import selector
were used directly, but it's package-private making that unlikey. In
such circumstances a NullPointerException was being thrown.
This commit asserts that the attributes are non-null and, should the
assertion fail, produces an error that is more helpful than an NPE.
Closes gh-1512
Enhance JacksonAutoConfiguration to configure features on the
ObjectMapper it creates based on the following configuration
properties:
spring.jackson.deserialization.* = true|false
spring.jackson.generator.* = true|false
spring.jackson.mapper.* = true|false
spring.jackson.parser.* = true|false
spring.jackson.serialization.* = true|false
The final part of each property name maps onto an enum. The enums are:
deserialization: com.fasterxml.jackson.databind.DeserializationFeature
generator: com.fasterxml.jackson.core.JsonGenerator.Feature
mapper: com.fasterxml.jackson.databind.MapperFeature
parser: com.fasterxml.jackson.core.JsonParser.Feature
serialization: com.fasterxml.jackson.databind.SerializationFeature
Closes gh-1227
Previously, JTA auto-configuration would fail with a variety of
ClassNotFoundExceptions and NoClassDefFoundErrors if it was used with
an “incomplete” classpath. This commit adds a number of classes to
@ConditionalOnClass annotations so that the auto-configuration backs
off gracefully in the absence of certain classes.
Specifically, the following now work as expected:
- Deploying an app to a server with JTA available via JNDI when the
app does not use transactions
- Auto-configuration of Atomikos without JMS
- Auto-configuration of Bitronix without JMS
Both XADataSourceAutoConfiguration and JndiDataSourceAutoConfiguration
have been updated to back off in the absence of spring-jdbc; a
dependency of DataSourceProperties which is used by both classes.
Error handling in AtomikosDependsOnBeanFactoryPostProcessor and
BitronixDependentBeanFactoryPostProcessor has been enhanced so that the
correct dependencies are established, even in the absence of JMS.
Fixes gh-1538
With this change I got a simple Eclipselink version of the data-jpa
sample working. I'll push that when I get time to research it a bit more
(I needed to set up a Java agent so either that might be a problem
for our integration tests if we can't work around it).
Fixes gh-1268. Cherry picked onto master after (apparently) a failed
merge of commit ac2ab39.
Protecting /error doesn't make a great deal of sense and if it is
protected you don't get the ErrorPageFilter for the attempt at loading
it, so Tomcat renders its own HTML error page (when deployed as WAR).
Fixes gh-1548
There was too much state really in the old implementation of
AuthenticationManagerConfiguration, and it was leading occasionally
to null pointers when method A assumed that method B had already
been called and it hadn't. This change manages to concentrate all the
references to an AuthenticationManagerBuilder into a single method
call, removoing the need for storing it at all.
Fixes gh-1556
Spring Data Redis 1.4.0 introduced Redis Sentinel support. When
specified, RedisConnectionFactory uses the Sentinel configuration to
determine the current master.
Sentinel configuration can be specified using two new properties:
spring.redis.sentinel.master and spring.redis.sentinel.nodes.
For example:
spring.redis.sentinel.master=mymaster # name of redis server
spring.redis.sentinel.nodes=127.0.0.1:26379,127.0.0.1:26380
Alternatively, a bean of type RedisSentinelConfiguration can be declared
and it will be used to configure the connection factory.
Note: At this time, Sentinel support is only available for Jedis
Closes gh-1337
The missing bean condition on the auto-configuration classes for
Elasticsearch, Jpa, Mongo and Solr repositories have been tightened to
look for ElasticsearchRepositoryFactoryBean, JapRepositoryFactoryBean,
MonoRepositoryFactoryBean, and SolrRepositoryFactoryBean respectively.
In Spring Data Evans, when there are multiple repository types on the
classpath, a strict mode is entered to prevent the different
repositories from trampling over each other. A side-effect of this is
that for the Mongo domain types in the tests to be discovered they
must be explicitly annotated with @Document.
Closes gh-1338
This commit adds two additional auto-configuration items that are new
in Spring AMQP 1.4:
* A RabbitMessagingTemplate is automatically created if none is present
* A default RabbitListenerContainerFactory is automatically created if
none is present.
Besides @EnableRabbit is enabled automatically if the necessary classes
are present and a ConnectionFactory is available.
Fixes gh-1495
Replace @ConditionalOnBean(MongoProperties.class) on
MongoDataAutoConfiguration with @EnableConfigurationProperties since
MongoAutoConfiguration will not be applied in a cloud environment.
Fixes gh-1502
Add a test to JmxAutoConfigurationTests which verifies that
@EnableIntegrationMBeanExport can be used on a @Configuration class
to customize the default domain used for MBeans created by Spring
Integration. See https://jira.spring.io/browse/SPR-12128.
Closes gh-1451
Add `AnyNestedCondition` which can be used to create a logical 'or' of
other conditions contained on nested classes. For example:
static class OnJndiOrProperty extends AnyNestedCondition {
@ConditionalOnJndi()
static class OnJndi {
}
@ConditionalOnProperty("something")
static class OnProperty {
}
}
Fixes gh-1490
Add additional constructor and a protected postProcessConverters method
to make it easier to manipulate the final converter list that will
be used.
Fixes gh-1482
Update HornetQConnectionFactoryConfiguration and
HornetQXAConnectionFactoryConfiguration so that they no longer depend
on the HornetQ EmbeddedJMS class. EmbeddedJMS beans are started
(when possible) from the HornetQConnectionFactoryFactory.
Fixes gh-1480
Import DataSourcePoolMetadataProvidersConfiguration from
DataSourceAutoConfiguration so that PoolMetadataProviders are configured
even if actuator is not used.
This commit improves DataSourceMetadata to expose the validation
query. This can be used by DataSourceHealthIndicator as the query
to use instead of "guessing" which query could be applied according
to the database type.
Fixes gh-1282
This commit binds RepositoryRestConfiguration to the spring.data.rest
prefix so that any of its property can be customized through the
environment.
If a RepositoryRestMvcConfiguration is defined in the context, those
customization do not apply, as it was the case before.
Fixes gh-1171
Update auto-configuration for JMS and JTA to support a ConnectionFactory
and TransactionManager exposed via JNDI.
JTA configuration now attempts a simple JtaTransactionManager before
attempting Bitronix or Atomikos configuration.
The JMS auto-configuration also now attempts to find a ConnectionFactory
from JNDI before falling back to the previous strategies. If JNDI is
present a JndiDestinationResolver is also configured instead of the
default DestinationResolver.
See gh-947
Automatically apply @EnableJMS when spring-jms is on the classpath
and the annotation hasn't already been applied. This allow for Spring's
new @JmsListener annotation to just work.
Fixes gh-1425
Add `spring.datasource.jndi-name` property to allow a DataSource to be
looked up from JNDI as an alternative to defining a URL connection.
Fixes gh-989
Velocity and Freemarker share some common properties so the base class for
configuring their properties makes some sense. Unfortunately the implementation
pulls in Spring MVC at runtime because of the signature of one method (that
would never be called). We can fix that in a number of ways, but the least
disruptive is probably to change the signature of that method and only refer
to the concrete template view resolver type if the method is called.
Fixes gh-1437
We can't easily solve the problem by not allowing Spring Security to
eagerly instantiate everything, but we can be defensive about data.sql
and make sure it is executed even if the listener isn't yet registered.
Fixes gh-1386
Fix DataSourceProperties getUsername() and getPassword() methods to
call getDriverClassName() rather than using `this.driverClassName` to
ensure than deduced driver classes can be used.
Fixes gh-1421
Update the the PathMatchingResourcePatternResolver used in the
MessageSourceAutoConfiguration condition to deal with the fact
that `classpath*:` patterns do not work with URLClassLoaders when
the pattern doesn't include a folder.
The ExtendedPathMatchingResourcePatternResolver works by searching
all classpath URLs when the `findAllClassPathResources` method is
called with an empty location.
Fixes gh-1378
Update MongoAutoConfiguration to be conditional on a missing
MongoDbFactory bean. The assumption is that if the user has declared
a MongoDbFactory they will either use it directly, or they will also
register a Mongo bean.
If the MongoDbFactory class cannot be found the existing Mongo
auto-configuration still applies. This ensures that users that do
not have Spring Data can still access a Mongo bean.
Fixes gh-1341
Enable if all of the following are true:
- spring-cloud is on the classpath
- There is no Cloud bean present
(usually done by extending AbstractCloudConfig)
- The "cloud" profile is active
Fixes gh-1302
Autoconfigure spring-cloud
if user also adds @EnableWebMvcSecurity. The problem is that the ordering
of the init() and configure() methods in the Spring Security configurers
can force things to happen too early unless we are careful. It's still a bit
twitchy I would say, but this relatively small change seems to fix the GS guide
and not break any existing tests.
I added a sample which mimic ths GS guide so we get an integration test that
executes the new code paths.
Fixes gh-1364
This commit adds two additional auto-configuration items that are new
in Spring 4.1
* A JmsMessagingTemplate is automatically created if none is present
* A default JmsListenerContainerFactory is automatically created if
@EnableJms has been triggered and no default has been set manually
Fixes gh-1298
Previously, the data scripts were always run in response to the
publication of a DataSourceInitializedEvent, irrespective of
spring.datasource.initialize. While the event won't be published by
DataSourceInitializer if spring.datasource.initialize is false, it
will be published if spring.jpa.hibernate.hbm2ddl.auto has been set.
This commit updates DataSourceInitializer's handling of
DataSourceInitializedEvent to only run the data scripts if
spring.datasource.initialize is true.
Fixes#1336
Rename the newly introduced @ConditionalOnProperty `match` and
`defaultMatch` attributes to `havingValue` and `matchIfMissing`.
Also added a new `name` attribute as an alternative to `value` to
aid readability.
Closes gh-1000
The original fix for gh-1293 (commit 05e6af23) caused test failures due
to the fact that Spring Boot's MappingJackson2HttpMessageConverter was
added before Spring's default StringHttpMessageConverter.
This commit changes the HttpMessageConverters logic so that additional
converts are added just before any default converter of the same type.
This allows additional converters to be added whilst still retaining
the sensible ordering of the default converters.
Fixes gh-1293
It was incorrect to simply replace existing instances because you can't
tell from the instance which media types and java types it supports. This
fix just prepends the custom converters so they get higher priority.
Fixes gh-1293
With this change I got a simple Eclipselink version of the data-jpa
sample working. I'll push that when I get time to research it a bit more
(I needed to set up a Java agent so either that might be a problem
for our integration tests if we can't work around it).
Fixes gh-1268.
This commit merges the features of @ConditionalOnPropertyValue
to the existing @ConditionalOnProperty.
The "match" attribute provides the value to match against. By default,
the value should not be equal to "false" which is the existing default
of @ConditionalOnProperty. "defaultMatch" specifies if the value
should be present. The default matches also the existing behavior of
@ConditionalOnProperty.
Fixes gh-1000
This commit adds a new conditional annotation that checks if a
property has a given value. This allows to replace constructs
such as
@ConditionalOnExpression("'${app.myProperty:foo}' == 'foo'")
to
@ConditionalOnPropertyValue(property="app.myProperty",
value="foo", defaultMatch=true)
Which is definitely more verbose but has the following advantages:
1. Works by default if the actual property in the environment is
a bit different (i.e. my-property)
2. Works if the value of the property has a diferent case (FoO or
FOO would match)
3. Gives a precise reporting in the auto configuration report
The defaultMatch flag is meant to mention that the condition should
also match if the value is not set; the auto-config report would
also have an explicit report about it.
Fixes gh-1000
This commit uses dedicated Properties classes instead of accessing
the raw environment for Spring Social and Spring Mobile. This
improves the readability and the discovery of such properties.
Fixes gh-1238
The problem with the old code is that it worces a ResourceBundle to
initialize with the default encoding (and that is then cached in the
JDK) during @Condition evaluation (so before the encoding is known).
Includes test for swedish messages
Fixes gh-1228
Due to a mistake in Spring Batch 3.0.0 it has been necessary to
introduce a breaking API change (the addition of
BatchConfigurer.getJobExplorer()) in the 3.0.1 release. This commit
updates Boot to use 3.0.1 and modifies the Batch auto-configuration
and associated tests to implement the new method.
User can now add credentials, vhost and protocol prefix (amqp://)
to any or all of the addresses, extending the format beyond that accepted
bu the rabbitmq client, but making it cloud friendly. Only one of
the addresses needs those properties and all are optional. Port
also defaults to 5672 in an address.
The DataSourceInitializer is instantiated early by the
DataSourceInitializerPostProcessor, so it has to live in
isolation (in its own @Configuration) to prevent early
instantiation of the DataSourceAutoConfiguration.
Fixes gh-1166
bean from the registration of Jackson modules to avoid circular creation
of the default ObjectMapper bean (and thus failing to obtain the ObjectMapper
and registering the module(s)).
Fixes gh-1132
Adding an Order to the BeanPostProcessor and catching an exception
are enough to get a simple web app with @EnableGlobalMethodSecurity
and JDBC user details running. It actually doesn't solve an underlying
problem in Spring Security, but I'll deal with that separately.
See gh-1115
Update SolrAutoConfiguration to specifically require HttpSolrServer
and CloudSolrServer classes rather than the generic SolrServer.
This prevents the rather cryptic "@ConditionalOnMissingBean annotations
must specify at least one bean" error that can occur if an earlier
version of solr happens to be on the classpath (as is the case when
hibernate-search is used).
Fixes gh-1098
Refine auto-configuration for Spring Social to:
- Only auto-configure FB/Twitter/LinkedIn if the `app-id` property is
set.
- Only configure ConnectController and ProviderSignInController if
there is a ConnectionFactoryLocator.
- Auto-configure Spring Social's SpringSocialDialect for Thymeleaf if
Thymeleaf is present.
- Added several tests around Spring Social auto-configuration.
Fixes gh-1118
It needs to run as soon as the DataSource is available really otherwise
anything else that depends on the DataSource (like Security JDBC
initializers) might fail when it tries to use it.
One change from 1.1.1 is that if you have a schema.sql you had better
make sure your data.sql talks to the same tables. In 1.1.1 you could
sometimes get away with letting Hibernate initialize the tables for
your data.sql and *also* have a schema.sql. This was fragile and doomed
to fail eventually if the DataSourceInitializer somehow got
initialized earlier (e.g. through a @DependsOn), so in the spririt
of honesty being the best policy we explicitly disallow it now.
Fixes gh-1115
Prior to this commit it was not safe to start several contexts
using the HornetQAutoConfiguration in the same VM. Each context
was trying to start their own HornetQ embedded broker by default but
only the first was really starting. Worse, the various InVM connection
factories were all silently connecting to the first broker.
This commit introduces a new "serverId" property that is an auto-
incremented integer by default. This identifies the server to connect
to and allows each context to start its own embedded broker in total
isolation of other contexts.
This commits makes it possible for a context to disable its own
embedded broker and connect to an existing one, potentially started
by another context.
Fixes gh-1063
Prior to this commit, some tests were creating a parent/child
relationship but were only closing the child context. This could
be an issue with the autoconfig module as a lot of auto-config
kicks in by default.
This commit adds a new test utility designed to properly handle
those situations. Updated tests that were creating a context
hierarchy to benefit from that.
Fixes gh-1034
To ensure an MBeanServer is available when needed you have to
look in JNDI before resorting to the JDK platform factory.
I had to copy some private code from Spring, but it seems
worth it.
Fixes gh-1092
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
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
Registers required components in application context if not available to
set up environment for usage with Spring Data Solr. Will listen on
SolrServer and SolrRepositories for configuration.
By default an HttpSolrServer is registered unless a zkHost (zookeeper
host) is defined. In that case an instance of CloudSolrServer will be
created.
By default multicore support is enabled, creating instances of
SolrServer for each core defined via @SolrDocument.
OnBeanCondition has some issues with FactoryBean object types where
the FactoryBean is not generic (i.e. you have to instantiate it to
get its object type). This is a known issue (see tests in
ConditionalOnMissingBeanTests), but we can provide some help for
library authors who know the type in advance. The approach we have
taken here is to check the BeanDefinition for an attribute called
"factoryBeanObjectType" (OnBeanCondition.FACTORY_BEAN_OBJECT_TYPE)
which, if it exists, can be used as a tie-breaker. Its value should
be a Class<?> instance.
Fixes gh-921
- Remove dependency management for projects that Boot does not have a
runtime dependency upon
- Provide dependency management for all of Spring Batch’s modules
Since Flyway has bean properties (with getters and setters)
it can be used to bin directly to the Environment (instead of
copying all the properties into FlywayProperties).
Fixes gh-806
A callback is added in autoconfig, so that if users inject the EntityManagerFactoryBuilder
into their app and use it to create multiple EntityManagerFactories, they all get the
same deferred DDL behaviour. The deferred DDL can also be disabled by setting
spring.jpa.hibernate.deferDdl=true.
Fixes gh-894
The EntityManagerFactory will happily process the DDL on startup, but
that happens too early (because of LoadtimeWeaverAware processing). We
can defer it to a more civilised stage, e.g. ContextRefreshedEvent by
using the Hibernate native APIs directly.
It makes the JpaProperties slightly more complex because they need
to distinguish between the early init and late processing versions
of the Hibernate properties.
Not ready for prime time yet because there is no way to deal with
multiple EntityManagers.
Fixes gh-894
Since groovy-templates is included with groovy-all it is unreasonable
to expect anyone who has it on their classpath to have resolvable templates.
We may need to revisit this decision, but since the origain feature
that drove this was thymeleaf and idaiotic users having it on their
classpath but not using it, maybe we don't need to.
Default suffix .tpl. If groovy-templates is on the classpath user
can now add templates and get them rendered and resolved in an MVC
app.
TODO: Macro helpers for message rendering etc.
See gh-878
- Add createConnectionFactory method on ActiveMQProperties
- Change getBrokerUrl to return the broker URL and add new deduce method
- Move static methods to end of class
- Apply source formatting
Update all @PostConstruct methods to ensure that they don't throw
checked exceptions. Required to allow deployment of Spring Boot
applications on Glassfish.
Fixes gh-868
Since ActiveMQ 5.8.0, the modules structure has been revisited and
activemq-core no longer exists. The activemq-broker is required to
create an embedded broker. Since Boot creates such broker by default
if ConnectionFactory is present, a condition has been added to do so
only when the necessary classes are present in the classpath.
The default embedded broker is now configured to disable message
persistence altogether as this requires an extra jar since 5.8.0, i.e.
activemq-kahadb-store.
Split the ActiveMQ auto configuration from the JmsTemplate auto
configuration so these are totally independent.
ActiveMQAutoConfiguration has been created to detect and configure
the ActiveMQ broker if necessary.
The brokerUrl parameter was ignored as long as the inMemory parameter
was true. The actual brokerUrl to use is now determined by the user
defined values of those parameters: if the brokerUrl is set, it is always
used. If no brokerUrl is set, the value of inMemory determines if an
embedded broker should be used (true) or a tcp connection to an
existing local broker (false).
JmsTemplateAutoConfiguration now creates a JmsTemplate only if a
ConnectionFactory is available.
Fixes gh-872, gh-882, gh-883
Adds JpaProperties to bind to spring.jpa.* (making those
properties easier to reason about and visible in the
/configprops endpoint).
Also allows easy configuration of multiple EntityManagerFactories via new
EntityManagerFactoryBuilder. JpaBaseConfiguration has a @Bean of that type
so users can inject it to create new or additional EntityManagerFactories.
This also simplifies the Hibernate autoconfiguration.
Also renames the DataSourceFactory to DataSourceBuilder (since that's what it
is).
We now have a much simpler DataSourceAutoConfiguration that binds to whatever
DataSource concrete type it finds at runtime. To be able to quickly switch between
Hikari and the other types of DataSource there's a minute shim for translating
the common properties (username, password, url, driverClassName), but actually
only url is different. The shim and also DataSource initialization is supported
through DataSourceProperties, but the other native properties get bound directly
through the concrete runtime type of the DataSource.
The /configprops endpoint works (and is exposed in the actuator sample).
Fixes gh-840, fixes gh-477, see also gh-808.
Update the BasicErrorController so that it no longer needs to implement
@ControllerAdvice or have an @ExceptionHandler method.
A new ErrorAttributes interface is now used to obtain error details,
the DefaultErrorAttributes implementation uses a
HandlerExceptionResolver to obtain root exception details if the
`javax.servlet.error.*` attributes are missing.
This change also removes the need for the extract(...) method on
ErrorController as classes such as WebRequestTraceFilter can
now use the ErrorAttributes interface directly.
See gh-839, gh-538
Fixes gh-843
We might need to revisit this to allow more fine-grained
control by users, but it seems like a sensible default.
The BasicErrorController now uses both of the deafult strategies
(ResponseStatusExceptionResolver and DefaultHandlerExceptionResolver)
from Spring MVC to try and determine an appropriate response.
Fixes gh-839
For the convenience of users who want to selectively override the
access rules in an application without taking complete control of the
security configuration we now have some constants:
* SecurityProperties.ACCESS_OVERRIDE_ORDER for overriding just the
application endpoint access rules
* ManagementServerProperties.ACCESS_OVERRIDE_ORDER for overriding the
application endpoint and management endpoint access rules
Fixes gh-803
In addition to the upgrade to Dijkstra (#743) Spring HATEOAS has been
upgraded to 0.11.0 (#801) and Mongo's Java driver has been upgraded to
2.12.1 (#689). In both cases this is the same version as is used by
Dijkstra RC1.
The new version of Mongo's Java driver changes the exception that's
thrown when Mongo isn't running and a connection attempt fails. The
Mongo sample has been updated accordingly.
RepositoryRestMvcAutoConfiguration has been updated to be configured
before JpaRepositoriesAutoConfiguration. This ensures that the
former's transitive import of SpringDataJacksonConfiguration takes
precedence over the latter's import of the same. This is necessary as
RepositoryRestMvcConfiguration requires a bean that's declared by
SpringDataJacksonConfiguration and, if JpaRepositoriesAutoConfiguration
is processed first, its conditions may cause the import
SpringDataJacksonConfiguration to be skipped causing instantiation
of RepositoryRestMvcConfiguration to fail.
Closes#689Closes#743
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
Previous to this commit, the remote shell security configuration
described that a default password will be generated with no extra
configuration. Actually, when Spring Security is configured for the
application, the remote shell reuses that configuration by default.
It turns out that the default log message is confusing as it was
referring to "application endpoints". Updated that log to a more
generic log message and updated doc accordingly.
Fixes gh-779
Restore `freemarker.template.Configuration` bean for the
FreeMarkerWebConfiguration. The @Bean method no longer uses a
@Condition since `FreeMarkerConfig` must already exist.
If Liquibase is on the classpath it will fire up on startup. Various
config options are available (as well as the option to disable it).
Liquibase uses a YAML format for changes (in classpath:db/changelog).
Remove `freemarkerConfiguration` from the FreeMarkerAutoConfiguration
since it should not be needed for most applications.
The previous code also caused problems since it included a
@ConditionalOnBean annotation on a bean that was created in the same
configuration.
The existing freemarker support only works in a webapp. This
change adds a FreeMarker Configuration bean (in both web- and
non webapps) so it can be used to load a Template and render it
(e.g. with Spring's FreeMarkerTemplateUtils).
See gh-679
Two modules are still relying on the spring-boot test-jar but it was
not generated anymore. Adding the generation of test-jar again as
a workaround until we completely removes the use of it.
We still prefer Tomcat if it is available (that can change
if the community asks loudly enough). Hikari is supported
via the same spring.datasource.* properties as Tomcat (and
DBCP), with some modifications:
* The validation and timeout settings are not as fine-grained
in Hikari, so many of them will simply be ignored. The most
common options (url, username, password, driverClassName) all
work as expected.
* The Hikari team recommends using a vendor-specific DataSource
via spring.datasource.dataSourceClassName and supplying it with
Properties (spring.datasource.hikari.*).
Hikari prefers the JDBC4 isValid() API (encapsulates vendor-
specific queries) which is probably a good thing, but we
haven't provided any explicit support or testing for that yet.
Fixes gh-418
This commit adds auto-configuration and a starter,
spring-boot-starter-freemarker, for using FreeMarker view templates in
a web application.
A new abstraction, TemplateAvailabilityProvider, has been introduced.
This decouples ErrorMvcAutoConfiguration from the various view
technologies that Spring Boot now supports, allowing it to determine
when a custom error template is provided without knowing the details of
each view technology.
Closes#679
Salvatore has indicated that Jedis is his Java Redis client of choice.
This commit updates the auto-configuration support, actuator and
Redis starter accordingly.
Completes #745
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
For some reason the exception mappings are only created with the
publisher is initialized in the constructor of DefaultAuthenticationEventPublisher.
Changed SpringBootWebSecurityConfiguration to do that rather then
relying on the ApplicationEventPublisherAware behaviour to inject it.
Fixes gh-719
The username/password option stil lonly works for a single host (to
connect to a cluster I suspect you need to set the URI). Also added
a MongoClientOptions (if a bean of that type exists it will be
used to populate the options that aren't in the URI).
Fixed gh-536
Polish couchbase support to:
- Extract properties into its own class
- Remove unnecessary inner configuration class
- Add since tags
- Format code and add `this.` references
Prior to this commit, a JmsTemplate bean created automatically by Boot
had its "pubSubDomain" flag enabled. It's far more usual to fallback on
queue rather than topic.
This commit flips the default value of the configuration property.
If the user sets spring.mvc.locale and doesn't provide a @Bean
of type LocaleResolver then a FixedLocaleResolver will be provided.
Fixes gh-697, fixes gh-669
User can specify the content type in external properties now, optionally
ommitting the charset (since that is duplicated). If charset is not
appended by user Spring will do it.
Fixes gh-671
A more thorough check is needed to avoid the false assumption
that the DataSource is embedded just because an embedded database
is on the classpath. You really have to try and look in the connection
metadata, so that's what we now do.
Fixes gh-621, fixes gh-373
Update AutoConfigurationPackages to log warnings on the first access,
rather than during setup. This works around the fact that the CLI
currently add multiple @EnableAutoConfiguration annotations.
Fixes gh-579
The management security autoconfiguration wanted to come last in the chain
but that won't suit the fallback that was already in place for gh-568. This
change re-orders the autoconfig so that @EnableWebSecurity is still added
if the user sets security.basic.enabled=false and includes the actuator
endpoints.
Fixes gh-568
If the user explicitly disables the basic security features and forgets to
@EnableWebSecurity, and yet still wants a bean of type
WebSecurityConfigurerAdapter, he is trying to use a custom
security setup and the app would fail in a confusing way without
this change.
Fixes gh-568
Introduce an extra `server.tomcat.uri-encoding` property used to
configure the URI encoding for the embedded tomcat container.
Defaults to `UTF-8` instead of the usual tomcat default of `ISO-8859-1`.
Fixes gh-540
If the user provides a JobExplorer and a BatchConfigurer that
don't require a DataSource we can back off on configuring ours
(and anything else that needs a DataSource).
Fixes gh-561
ErrorPageFilter is itself an EmbeddedServletContainerFactory
but it runs in a non-embedded container. Any component that assumes
the presence of an EmbeddedServletContainerFactory implies we are
running embedded is therefore invalid. WebSocketAutoConfiguration
had that problem.
Fixes gh-551
The bean ID for the ContentNegotiatingViewResolver is now
"viewResolver" (it is the *one*). The conditions have been changed
so that a user only has to define a bean of the same name to switch
it off.
Fixes gh-546
Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
This is quite a big step, but I think it helps a lot. Since Spring
Boot always creates an AuthenticationManager if it doesn't find one
already registered, it makes sense to also make it into a @Bean.
Spring Security does not register its AuthenticationManager by
default though, so we have to do that for it if the user has created
one with an @Autowired AuthenticationManagerBuilder, but not registered
it as a @Bean.
Having the @Bean (marked @Primary to prevent issues with @Autowired)
makes it easier to reason about what Spring Boot has done for you, and
easier to default in simple use cases to the boot-created
AuthenticationManager. For example, if I want an OAuth2 Authorization
Server with password grant, it makes total sense for the
AuthenticationManager for users to be the same as the @Primary one.
Now it is easy to set that up (just @Autowire it).
Phillip Webb
Dave Syer
Andy Wilkinson
Dave Syer
Christoph Strobl
David Liu
Stephane Nicoll
Spring Buildmaster
Josh Long
Ramnivas Laddad
Phillip Webb
Oliver Gierke
Max Bruchmann
Andy Wilkinson
Stephane Nicoll
Gary Russell
Toshiaki Maki
Jonas Bergvall
Phillip Wirth
Roy Clarkson
Craig Walls
Artur Konczak
apoplexy
Christoph Strobl
Maciej Walkowiak
Christian Dupuis
Lukasz Kryger
Greg Turnquist
Marcel Overdijk
Artem Bilan
sopov.ivan
Josh Long
Michael Nitschinger
Rob Winch
Jean Detoeuf
Chris Savory
Piotr Maj