WAR applications should extend SpringServletInitializer to take advantage
of Servlet 3.0 initialization and SpringApplication context loading features.
[#48386505] [bs-52] Support for running "traditional" webapps in place
The ErrorEndpoint now handles text/html requests differently, delegating
to a View named "error". This view will not exist by default so the user
will see an ugly 500 error, but it's easy to fix and there isn't a good
to provide a default.
[Fixes#51214943]
Example: web UI with publicly available static assets
# application.properties:
security.ignored: /css/**,/script/**
Example: web UI with publicly available everything, but secure
management endpoints.
# application.properties:
# Empty path for basic security (default is /**)
security.basic.path=
[Fixes#50721675]
* One for Cloud Foundry and one for the application context ID
* If app runs in Cloud Foundry vcap.application.* and vcap.services.*
will be populated in the Environment
* The ApplicationContext ID is set to something supposedly unique
(e.g. name:index in a Cloud Foundry app)
[#50968415] [#48153639]
Update AbstractEmbeddedServletContainerFactory to detect the document
root from a classically packaged war file.
[#48386505] [bs-52] Support for running "traditional" webapps in place
Before this change if Layout dialect not available then the nested class is
loaded and barfs because it depended on the layout dialect (in a
@ConditionalOnClass annotation).
As per standard LiveBeansView features, if spring.liveBeansView.mbeanDomain
is set in the Environment, then all application contexts are displayed,
otherwise only the local one. Only JSON is served (via produces=).
[Fixes#50879457]
Previously EmbedddedContainerConfiguration cannot be imported directly.
This change ensures that the nested classes are not loaded automatically
so there can be no issues with the annotation parameters.
There might be a case for a change in Spring here since the framework
itself could just be more cautious when processing nested classes.
[Fixes#50880927]
Various parent context topologies are tried to ensure that the properties
are bound sensibly.
[#50804109] Allow @ConfigurationProperties beans to be declared
explicitly (to set default values)
User adds @OnManagementContext to a bean or @Configuration and
it should be included in the management context (if there is one)
whether it is the main context or a child.
Makes it easy to secure the management endpoints and keep
the rest open (see actuator-ui-sample).
[#50721675]
* The RegistrationBean (ServletInitializer) now exposes a registration
target object, and this is used to prevent double registration of those
objects.
* If there is a Servlet with bean id "dispatcherServlet" it is mapped to
"/" (unless already registered as a ServletRegistrationBean).
[Fixes#48645559]
E.g.
options {
option "foo", "Foo set"
option "bar", "Bar has an argument of type int"
withOptionalArg() ofType Integer
}
println "Hello ${options.nonOptionArguments()}: " +
"${options.has('foo')} ${options.valueOf('bar')}"
[#50427095] [bs-135] Plugin model for spring commands
* Added CommandFactory and a ServiceLoader model for providing
implementations
* Added ScriptCommand (wrapping groovy script). Service providers
are recommended to implement OptionHandler in their script, but a
regulare Script or a Runnable will also work.
[#50427095]
The delegating version delegates to other configurers, and it's what
@EnableWebMvc uses. You effectively switch off the delegation if you
use the base class by mistake.
[Fixes#50267017] [bs-132] Static resources in /css/**
cannot be served by Actuator project
* A simple check to see if it is already registered
fixed the original problem
* Also removed the need to have @ConfigurationProperties
on a bean class (unless you want to specify the target name
etc.)
[Fixes#50256421] [bs-130] When actuator app starts the
@ConfigurationProperties are registered with the bean
factory several times
Moved the Grab.addResolver() call to before any other compiler
customizations.
That got it working locally (removed ~/.m2 and ~/.groovy/grapes)
but still not working on cloudfoundry for some reason. We need
more help from buildpacks there (to get a cache going for the
grapes), but there seems to be more than just that stopping it
(maybe just timeouts?).
[#50351963]
* Added GroovyTemplate.template() utility and static import in webapp CLI, so
@RequestMapping("/")
@ResponseBody
String home(Model model) {
template "home.html", model
}
renders the template in /templates/home.html
[Fixes#49832753]
Dave Syer
Phillip Webb
Greg Turnquist