Rename ConfigurableEmbeddedServletContainerFactory to
ConfigurableEmbeddedServletContainer and extract
AbstractConfigurableEmbeddedServletContainer from
AbstractEmbeddedServletContainerFactory.
There's no explicit support for older Servlet specs in Spring Boot,
but we can at least make it easy for others to provide such
support by not adding stuff to the context when in an older container.
Some assumptions were being made in tests, e.g. about
there being an AuthenticationManager @Bean, which were
false with the new Security 3.2.1 updates from Rob.
Also parent-child contexts with the actuator were
problematic because they didn't exclude the web configuration
for the management security in the parent context.
Fixes gh-244
Also change strategy for defaulting of Authentication. Spring
Boot authentication defaults are now encapsulated and can easily
be overridden by a user defined AuthenticationManager.
The existing behaviour of JobLauncherCommandLineRunner was really too
basic. It has now been enhanced (at the expense of duplicating a lot
of code in Spring Batch it seems) to automatically increment job
parameters if it can, and to retry a failed or stopped execution
if it can (without incrementing, but with additional job parameters
added from command line if they are non-identifying).
The JobLauncherCommandLineRunner is more extendable and exposes
its DI wiring points now as well, so hopefully users can make
use of it independently of autoconfig (by providing a @Bean of
that type).
Not everything from the wishlist in gh-325 is implememented yet,
but it should be a good platform to work with and to extend.
Better even than logging would be to fail fast? Surely it's a
mistake not to have any /templates if Thymeleaf is in use.
User can disable failfast by exlcuding thymeleaf configuration
or by providing their own ITemplateResolver.
Fixes gh-294
User can switch the behaviour on and off with
spring.datasource.continueOnError:true|false. I decided
not to add an extra nested level of property resolution
because of the existing spring.datasource.schema
(and other properties relating to initialization) because
concision seemed like a good thing with those more common
settings.
Fixes gh-374
The DispatcherServletAutoConfiguration had a condition on it that
meant it wasn't used at all if there was no EmbeddedServletContainerFactory.
It's amazing that any WAR ever deployed.
Also added some info logging to servlet and filter registrations.
Update OnBeanCondition to attempt to consider FactoryBean classes
for bean type matches. To ensure early instantiation does not occur, the
object type from the FactoryBean is deduced by resolving generics on the
declaration.
Fixes gh-355
Update AbstractRepositoryConfigurationSourceSupport to use the newly
introduced RepositoryConfigurationDelegate instead of effectively
reimplementing Spring Data Commons functionality which was prone to
changes in the API (code that wasn't considered to be API in the first
place).
Switch from implementing BeanClassLoaderAware to ResourceLoaderAware
to avoid having to set up a DefaultResourceLoader which should also
improve IDE integration.
Fixes gh-236
Disable Mongo auto-configuation when @EnableMongoRepositories is used
and adapt the test helper classes accordingly.
Change the property prefix and dependency management version property
from `...mongo` to `...mongodb` for consistency with Spring Data.
Fixes gh-315
Update SpringApplication so that ApplicationListener and
ApplicationInitializer methods must be called separately. This helps
to prevent unexpected side effects when calling the setters and
also encourages separation of concerns.
The few situations where a class was both an ApplicationInitializer
and ApplicationListener are now handled by registering an inner
listener from the `initialize` method.
BeanFactory.getBean() already looks in the parent context
so we have to be careful and not use the parent when locating
the report singleton
Fixes gh-290
Spring Boot provides a default AuthenticatiomManager for getting
started quickly with security and never exposing insecure
endpoints. To override that feature as users move to the next
stage in their project, they may have to do something slightly
different depending on whether it is a webapp or not.
In any app (web or not), providing a @Bean of type
AuthenticationManager always works, but you don't get the benefit of
the builder features.
In a webapp the user can also extend WebSecurityConfigurerAdapter
to provides a custom AuthenticationManager, and the preferred
way of doing that is via a void method that is autowired with an
AuthenticationManagerBuilder. The default AuthenticationManager is
built in a configurer with @Order(LOWEST_PRECEDENCE - 3) so
to override it the user's confugrer must have higher precedence
(lower @Order).
@EnableGlobalMethodSecurity can also be used in a non-webapp, and
Spring Boot will still provide a default AuthenticationManager.
To override it the user has to either extend
GlobalMethodSecurityConfiguration or provide a @Bean of type
AuthenticationManager (there's no other way to
capture the AuthenticationManagerBuilder that doesn't happen too late
in the beans lifecyle).
Fixes gh-244
If any @Import (or @Enable*, especially @EnableScheduling) has registered
bean *names* as ApplicationListeners, and the application context wasn't
refreshed fully when it failed, then the listener lookup could fail and
mask the original exception
Fixes gh-253
Update the 'default' package used for @Entity and Repository scanning
to be the package of the class annotated with @EnableAutoConfiguration
rather than using @ComponentScan.
This allows JPA and Spring Data to be used without requiring component
scanning and also removes the confusion that could arise from reusing
the @ComponentScan annotation, which already has well defined semantics.
Fixes gh-200
Refine the `AutoConfigurationReportLoggingInitializer` log level to
only display the information about enabling debug if the debug level
if not on.
Fixes gh-199
Update the `AutoConfigurationReportLoggingInitializer` to only output
the report at debug level. A crash report now triggers an info output
suggesting the user runs again with '--debug' to display the report.
Fixes gh-199
Add a new `SpringNamingStrategy` hibernate `NamingStrategy` that
extends `ImprovedNamingStrategy` to improve the name of foreign
key columns.
Fixes gh-213
Instead of adding active prpfiles for every one we encounter, we need to
build up a complete "default" Environment and then ask it what the active
profiles are. Implemented in ConfigFileApplicationListener.
Fixes gh-198
Also logs a warning about the fact that locks may not be taken when
starting a Job. JPA and Batch don't really work that well together
in general so it's probably not worth a lot of effort to work aoround
this. If anyone needs to they should create a custom JpaDialect
(and a BatchConfigurer).
Fixes gh-197
Fix the following issues that were introduced in commit 0610378:
- Formatting of code including imports
- Improve hashcode/equals implementations by using ObjectUtils
- Provide hashcode/equals for ConditionOutcome
- Use LinkedHashSet in ConditionAndOutcomes to maintain insert order
Fixed gh-127
The collection of outcomes is a list. Sometimes a race condition causes to instances
of the same outcome to get added to the list shown in the report. By replacing this
with a set and propery equals/hashCode, duplicates are prevented from appearing
in the report.
I added test cases to prove that that POJO is properly managed inside a Set and also
to show that duplicates don't appear in the final report.
Autoconfiguration ordering has to be adjusted so that a DataSource is
available before an EntityManagerFactory is ever needed. Previously
the autoconfigs were accidentally loaded in the right order, but after
the change to BatchAutoConfiguration the order has to be explicit.
Fixes gh-189
Added the necessary @ConditionalOnMissingBean annotations to allow selectively declaring an EntityManagerFactoryBean, a JpaVendorAdapter or a PlatformTransactionManager. Especially the first one might be necessary to make sure the persistence provider evaluates an orm.xml. This unfortunately rules out using the packages to scan feature of Spring's LCEMFB.
I've filed https://jira.springsource.org/browse/SPR-11260 to potentially remove the need for this workaround in Spring itself.
We get more control over the handling and in particular the registration
of the endpoint this way. It was practically impossible to disable the
AgentServlet bean when in a parent context of the management server
because of lifecyce issues - you don't know that the user wants a
separate management server until too late.
This approach also makes it possible to test with spring-test MVC
support.
You can contribute additional HttpMessageConverters
by simply adding beans of that type in a Spring Boot
context. If a bean you add is of a type that would have been included
by default anyway (like MappingJackson2HttpMessageConverter for JSON
conversions) then it will replace the default value. A convenience
bean is provided of type MessageConverters (always available if you
use the default MVC configuration) which has some useful methods to
access the default and user-enhanced message converters (useful, for
example if you want to manually inject them into a custom
RestTemplate).
There are also some convenient configuration shortcuts for Jackson2.
The smallest change that might work is to just add beans of type
Module to your context. They will be registered with the default
ObjectMapper and then injected into the default message
converter. In addition, if your context contains any beans of type
ObjectMapper then all of the Module beans will be registered with
all of the mappers.
Previously it was @ConditionalOnMissingBean(CommandLineRunner.class)
which caued obvious problems when user wanted to add an unrelated
CLR.
Extended feature set so that a JobRegistry can also be used (with
spring.batch.job.name) and the whole idea can be switched off with
spring.boot.job.enabled.
ServerProperties formerly had an @OnMissingBeanCondition
that didn't restrict the hierarchy. It also asserts that
the current context (not including parents) contains such
a bean. This led to an inevitable failure when there was
an existing instance in the parent context.
Fixed by a) searching only the current context, b) not
adding a ServerProperties bean if the context is not a
web app.
Previously all EventListeners were eagerly instantiated
but that can cause problems because it happens quite early
in the lifecycle. Better to be explicit about the
supported types.
This leverages existing capabilities of teh JDK and the OS
to grab a port at random and not have it stolen by another
process. It's very hard to avoid that race condition in
pure Java code, so why bother?
User can set port<0 to disable autoStart of connectors (e.g.
to start a web application context but not have it listen on
any port). In that case the actual socket port will be set to
0 (and therefore if it ever starts up the local port will
be random).
The AutoConfigurationReportLoggingInitializer wasn't working in
non-GenericApplicationContext becasue teh BeanFatcory wasn't available
for registering its listener during initialization. Instead of
relying on that rather fragile state I decided to give any
ApplicationContextInitializer that was itself an ApplicationListener
an explicit callback with a ContextRefreshedEvent, and move that
interface up a level in the logging initializer. Works much better.
Using containsBean() involves looking in the parent bean factory
if there is one, and that would mean that the same report woykd be used
for multiple contexts, which wouldn't make sense.
Update the auto-configuration report to improve log formatting and to
separate the internal report data-structure from the JSON friendly
endpoint data-structure.
- Gather autoconfiguration conditional decisiions (true and false)
- Provide an actuator endpoint as one means to read the report
- Define @EnableAutConfigurationReport annotation to turn this feature on
- Tidy up autoconfig report a bit and log it if --debug=true
To use a DataSource pool (Tomcat or DBCP) the user must supply a valid
driver class name *and* database URL. If both are supplied and the
driver class is not one of the embedded ones, then no default username
or password is provided.
Fixes gh-94
Use of hasMappingForPattern was commented out during work on the
Aether-based Grape implementation as it was temporarily removed in
Spring 4's snapshots. It's since been reinstated in the snapshots, so
its use should have been reinstated prior to merging Aether work into
master.
Previously, @Grab annotations would use Ivy to download the
dependencies with some of Ivy's known limitations being worked around
by GrapeEngineCustomizer.
This commit adds a GrapeEngine implementation that uses Aether,
the dependency resolution 'engine' used by Maven and Grails. To ensure
consistent behaviour with a Maven build, the Aether-powered dependency
resolution uses the dependency management configuration from the
spring-boot-starter-parent pom file.
Since ServerProperties had primitive properties for port (in
particular) it was not possible to check when applying those
properties if the user had actually changed the value. This
in turn meant that a custom EmbeddedServletContainerFactory
could not set the default values.
Fixed by making int properties of ServerProperties into
Integer and checking for null before setting on the
container factory.
Fixes gh-84
...for compatibility with Spring JDBC. Users can still
optionally specify spring.database.schema, but the default
location is schema-${spring.database.platform}.sql, schema.sql,
data.sql.
[Fixes#58332710]
Builder for SpringApplication and ApplicationContext instances with
convenient fluent API and context hierarchy support. Simple example
of a context hierarchy:
new SpringApplicationBuilder(ParentConfig.class)
.child(ChildConfig.class).run(args);
Another common use case is setting default arguments, e.g.
active Spring profiles, to set up the environment for an application:
new SpringApplicationBuilder(Application.class).profiles("server")
.defaultArgs("--transport=local").run(args);
If your needs are simpler, consider using the static convenience
methods in SpringApplication instead.
[#49703716] [bs-116] Parent context for some beans maybe?
- If RabbitTemplate is on the classpath, turn on autodetection.
- Create a RabbitTemplate, a Rabbit ConnectionFactory, and a RabbitAdmin is spring.rabbitmq.dynamic:true
- Enable some **spring.rabbitmq** properties like host, port, username, password, and dynamic
- Add tests to verify functionality
- Add Groovy CLI functionality. Base it on @EnableRabbitMessaging. Add spring-amqp to the path.
- Create rabbit.groovy test to prove it all works.
- Make Queue and TopicExchange top-level Spring beans in rabbit.groovy test script
* application.properties support for spring.jms and spring.activemq
* more tests to verify ActiveMQConnectionFactory pooling
* Groovy support and simple sample with activemq
* Groovy detection mechanism is @EnableJmsMessaging annotation
Update DataSource conditional to ensure that the driver class
can actually be loaded by the DataSource. This fixes an issue when
deploying a classic WAR where `org.apache.tomcat.jdbc.pool.DataSource`
is found the parent classloader but the database driver cannot be loaded
because is included as a local `/lib` dependency.
Adapted to changes in the API in Spring Data Commons which requires to pass in the current Environment into the AnnotationRepositoryConfigurationSource.
* Add ability to detect spring-jms on the path and create a JmsTemplate with
ActiveMQConnectionFactory
* Create tests showing autoconfigured JmsTemplate with ActiveMQ, but prove it
backs off if a separate ConnectionFactory exists.
* Add support to spring-boot-cli to that it detects JmsTemplate, DefaultMessageListenerContainer,
or SimpleMessageListenerContainer, and turns on autoconfiguration as well as
add proper @Grab's and import statements.
* Write a jms.groovy test showing proper CLI support
Simplify ActiveMQ configuration
Update ActiveMQ to 5.7.0
A side effect is that spring-boot-starter-data-jpa needs
to include an aspectjweaver depdendency. Hope that doesn't
hurt anything else.
[Fixes#56780004]
Remove '/resources/**' mapping since it can cause problems with the
'/**' when the developer defines their own 'resources' sub-folder.
Also remove default servlet config since the resources mapping renders
it redundant.
Issue: #55494446
The management endpoints were still all mixed up
with the user endpoints. Fixed that and extracted
user endpoints in to conditional block so not
protected if path explicitly set to empty string.
[#53029715]
Rework several aspects of database auto-configuration:
- Use RelaxedPropertyResolver to obtain property values
- Extract EmbeddedDatabaseConnection from EmbeddedDatabaseConfiguration
- Rename several configuration classes for consistency
Issue: #53028397
Update several existing auto-configuration classes to use the new
RelaxedPropertyResolver.
This commit also rename the spring.template property to spring.thymeleaf
in case we wish to support more templating engines in the future.
Opinionated defaults for WebSockets:
* If spring-websocket is on the classpath and so is
the Tomcat WSci initializer then it is added to the context
* A DefaultSockJsService is added if none is present
* User has only to define @Beans of type WebSocketHandler with
name starting "/"
* Each one is converted to a SockJsHttpRequestHandler and
mapped to "/<beanName>/**"
Change WebMvcAutoConfiguration to use WebMvcConfigurationSupport instead
of HanderAdapter as the @ConditionalOnMissingBean. This allows MVC to
be auto-configured even if you define additional HanderAdapters.
Issue: #55493342
Update AutoConfigurationUtils to specifically exclude spring-data-rest
packages from being stored. This prevent missing class errors caused
when Spring Boot attempts to use @ComponentScan packages as the source
for JPA entities and reads annotations that are not on the classpath.
Issue: #55489346
The DispatcherServlet adds a default InternalViewResolver
which was used by some apps, but when the actuator was
available it added an "/error" bean and effectively
switched off the default view resolver. The net fix was
to add an InternalViewResolver at the same time as
adding any other ViewResolvers.
[Fixes#55357516] [bs-290] Actuator UI app cannot serve static index.html
Create a new SpringBootCondition that will log why a condition has
or has not been applied. The removes the need for ConditionLogUtils
and simplifies many of the existing condition implementations.
Issue: #55203236
Update ConditionalOn annotations :
- Use consistent attribute names for OnClass and OnMissingClass
- Update javadoc
- Rename tests to reflect the annotation rather than the interface
* Exposed common pool properties in the base class for data source configuration
* Made it @ConfigurationProperties so it binds in strongly typed sense
[Fixes#53028455] [bs-214] Add pool parameters to AbstractDataSourceConfiguration
Instead of not installing one at all if there is any ServletContextInitializer,
Spring Boot will now install a DispatcherServlet if context does not contain one
already with the magic name "dispatcherServlet".
[Fixes#54674870] [bs-277]
* For a jar deployment add classpath:static/index.html
(works via Spring MVC mapping)
* For a war the same thing works, but so does adding
index.html to src/main/webapp (works via container
default servlet)
[Fixes#54092261] [bs-252]
Dave Syer
Phillip Webb
Rob Winch
Oliver Gierke
hoserdude
Christian Dupuis
Jakub Kubrynski
Christopher Smith
Andy Wilkinson
Greg Turnquist
Roy Clarkson
Eberhard Wolff
Phillip Webb
Dave Syer