Previously, RepositoryRestMvcBootConfiguration was not annotated with
@Configuration. This meant that it was processed in lite mode.
Crucially, in lite mode, there’s no proxying so each call to the
config() @Bean method from within other @Bean methods resulted in the
creation of a new RepositoryRestConfiguration instance. Furthermore, as
each of these instances wasn’t a Spring bean the configuration
properties were not applied.
This commit updates RepositoryRestMvcBootConfiguration to annotate it
with @Configuration so that it’s no longer processed in lite mode. It
also updates the unit tests and the Spring Data REST sample to verify
that the baseUri can be configured using application.properties.
Fixes gh-1675
Jersey 2 has some Spring support built in but it's a bit awkward to
use in a Boot app, so autoconfiguration seems appropriate. The tests
and sample show how to use it, but the short story is that any
@Component can define JAX-RS endpoints via @GET etc.
There's a sample for Jersey 1 as well (pay careful attention to
the plugin configuration if you want to build an executable jar)
Fixes gh-1651
Without the @Param annotations, using either of the search URIs would
resulted in a 400 response and an error describing the lack of @Param
annotation.
See gh-1627
If the actuator endpoints are configured on a different port then there
are some settings in the main ServerProperties that we would like to
re-use (e.g. the access log). The easiest way to do that is to just
configure the management server using the same ServerProperties instance
and then overwrite the things that are different (and stored in
ManagementServerProperties).
Fixes gh-1581
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
Prior to this commit, the repackage goal silently ignored the case of
two libraries having the same name and version but a different group.
As a result, the second library was overwriting the first one in the
repackaged jar.
This commit adds support for custom Library names and updates the
Maven and Gradle plugins so that the name includes the group ID
when there would otherwise be a duplicate.
Fixes gh-1475
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
Updates to prevent the maven-invoker-plugin from downloading remote
snapshot jars. Possibly caused by the recent changes to the
spring-boot-dependencies POM.
See gh-1413
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
Rename `VanillaHealthIndicator` to `ApplicationHealthIndicator` and
changed the exposed bean name from `statusHealthIndicator` to
`applicationHealthIndicator`.
This provides less confusing JSON output:
{"status":"UP","application":{"status":"UP"}}
vs:
{"status":"UP","status":{"status":"UP"}}
Fixes gh-1291
The request is being made to '/' and, while the application does have
a mapping for '/', that mapping is not looked for before Spring
Security's filter rejects the request with a 401. This means that the
request is considered to be unmapped and this is reflected in the
metric's name.
See #1331 and #1333
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
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
- upgraded Spring WS to 2.2.0.RELEASE
- replaced default MVC DispatcherServlet with MessageDispatcherServlet
- migrated XML based config with nww Spring WS Java config
Fixes: gh-412
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
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
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
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
when server.servletPath is set we need to add prefixes to
the security filter paths, and the /error path.
Conflicts:
spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/ManagementSecurityAutoConfiguration.java
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.
With this commit the state of a component or subsystem becomes a first-class citizen in Boot's application health support. HealthIndicators now return a Health instance with status and some contextual details.
An aggregation strategy has been introduced to aggregate several Health instances into one final application Health instance. Out of the box OrderedHealthAggregator can be configured to allow different ordering or a custom HealthAggregator bean can be registered.
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
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.
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
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).
This commit replaces the "index" property of Review to use a custom
column name ("idx") as index is a reserved keyword in some RDMS such
as Oracle and MySQL.
Fixes gh-752
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
Since Spring supports gobal error handling through
@ControllerAdvice, it is quite easy to set up more meta-data
about an exception for the BasicErrorController. You need
to be careful not to swallow Security exceptions, and probably
others (optionally) so this feature needs a bit more work.
See gh-538
This fixes a bug in the sample, where the AuthenticationManager it builds
is a local one for the filter chain containing "/login", whereas it was
expecting to override the Boot default, which is "global". The fix is
to extract the authentication configuration out into a
GlobalAuthenticationConfigurerAdapter.
Fixes gh-699
User can now set up default properties in the Environment using
@IntegrationTest("foo:bar", "x:y") etc. Using "server.port:0" you
can get Tomcat or Jetty to spin up on a random port. We also add
a test listener that populates "local.server.port" with the actual
port the server started on so you can @Value("${local.server.port}")
inject it into the test case.
See gh-607 (this should make the extension of that PR to samples
much easier)
Apparently springloaded 1.1.5 was released to Maven Central with a
different groupId than to repo.spring.io. It would have worked in
milestones because the repository was declared.
See gh-648
Spring Security doesn't know that Spring MVC maps /foo, /foo.json
and /foo/ all to the same handler. This change explicitly adds
suffixes to the actuator endpoint matchers so they are properly
protected.
Rename the RestTemplates to TestRestTemplate to help indicate that it's
primarily intended for testing. Also now extend RestTemplate to allow
direct use, rather than via factory methods.
Fixes gh-599
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
If the user sets security.basic.enabled=false he has to remember
to @EnableWebSecurity. Possibly we could be more helpful about the
exception, but I think this might be pilot error.
Fixes gh-568
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
Makes them a lot more readable IMO, and also enables @Autowiring
from the context into the test case (sweeet). I added @DirtiesContext
to all of them as well to be on the safe side, but possbly that can be
optimized in some way as well.
The management.contextPath property should now be respected in a
secure application, whether or not the management.port is different.
Added some test cases in the sample to verify.
Fixes gh-469
Use org.springframework.boot instead of ${project.groupId}
groupId in order to make it easier to use spring-boot-samples
modules as a starting point for new projects.
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
Requires Loaded 1.1.5 (or better).
For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).
For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).
In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].
The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.
Fixes gh-251, gh-183
Detect when an application is running in development (by the presence
of a build file) and automatically add a 'development' profile.
Additional detectors can be developed by implementing the
`ProfileDetector` interface and registering with the `SpringApplication`
Fixes gh-296
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
Add a new `SpringNamingStrategy` hibernate `NamingStrategy` that
extends `ImprovedNamingStrategy` to improve the name of foreign
key columns.
Fixes gh-213
Usage:
$ gradle bootRun
...
Edit files in src/main/resources and see the changes live in a web app
(e.g. static resources in /static).
The old functionality of bootRun has been replaced (since it didn't add
a lot of value and also didn't expose any JMV argument setters of anything).
This new feature set is backed by any existing "run" task configuration.
In addition autodetects a main class if there is one in the project
sources, so no need for mainClassName = '...' in build.gradle.
Applies the 'application' plugin (so no need to declare that either).
Fixes gh-225
Update SpringApplication to run by default in 'headless' mode. This
prevents the AWT system from creating a Java icon (for example in the
OSX dock).
Also update builds to run tests in 'headless' mode.
Long package names are really unnecessary in samples and they
just clutter things up. Also Spring Loaded doesn't work with
org.sfw packages, so to demo that technology you need a
different package name.
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
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.
When management endpoints are on a different port the HandlerMappings
are restricted to a single EndpointHandlerMapping, so the error
controller (which is a normal @Controller with @RequestMappings) does
not get mapped.
Fixed by addinga shim Endpoint on "/error" that delegates to the
ErrorController (which interface picks up an extra method).
- 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
This commit adds a new starter named spring-boot-starter-shell-crsh and auto configuration support to embed a system shell within Spring Boot applications.
The embedded shell allows clients to connect via ssh or telnet to the Boot app and execute commands. Commands can be implemented and embedded with app.
For sample usage see spring-boot-samples-actuator.
Previously the management endpoint filter was applied to all requests
if the user had disabled security.management.enabled, but since it
had no security applied it was letting all requests through.
The fix was to explicitly exclude the whole enclosing configuration
and carefully ignore the management endpoints in the normal security
chain.
Fixes gh-100.
In some cases the websocket communication fails and Snake#sendMessage throws an exception.
In that case the send loop is interrupted and later clients are not update.
The RC1 version had some websocket issues, that prevented propper websocket communication.
In some cases the SocketJS communication was downgraded to 'xhr_streaming'.
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?
Update SpringBootServletInitializer with separate getConfigClass() and
getAdditionalConfigClasses() methods. This change makes it easier to
use the SpringBootServletInitializer with the common use case of a
single config class.
The `Tomcat.start()` has to happen to initialize the `ServletContext`
but we can immediately stop the connector and then restart it when
the context is finished refreshing. Seems to make curl fail quickly
if an app is slow to start.
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]
Fix TomcatEmbeddedServletContainerFactory to set a MERGED_WEB_XML
attribute when JSPs are used. This is required for EL support with
JSPs since Jasper checks the version number in the web.xml. Without
any web.xml Jasper default to disabling EL.
Issue: #55752948
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