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.
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.
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
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.
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]
Also introduced new strategy for customizing Tomcat Context
(TomcatContextCustomizer) - any that are added to the factory
will be applied before any other customizations in postProcessContext()
[Fixes#54670052] [bs-275] Make Tomcat access valve logs more accessible
