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).
...bean with no explicit @Bean DispatcherServlet. We still have to check
by bean name (slightly unfortunate, but we need to avoid instantiating
too early) so there's now another magic
bean name for the registration bean ("dispatcherServletRegistration")
that the user has to replace if he wants the registration without
defining a servlet @Bean
Fixes gh-482
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
Upgrade to Tomcat 7.0.50, working around the potential
NullPointerException by also adding dependencies to
tomcat-embedded-jasper (which is now also required for Hibernate
Validator 5.0, see commit 377953babd)
Fixes gh-245
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.
Dave Syer
Stephane Nicoll
Phillip Webb
Chris Savory
Piotr Maj
Andy Piper
Josh Long
Spring Buildmaster
Rob Winch
Oliver Gierke
hoserdude
Christian Dupuis
Jakub Kubrynski
Christopher Smith
Andy Wilkinson
Greg Turnquist
Roy Clarkson
Eberhard Wolff