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
