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]
* Because Spring is not on the classpath we don't particularly
want to use SpringFactoriesLoader
* Adopted the JDK (>=6) ServiceLoader model instead
[Fixes#48789783]
* If the auto config class has a high Order it can check for
an existing transaction manager
* Unit tests added, and checked also witrh petclinic
[Fixes#50064347]
Dave Syer
Phillip Webb
Greg Turnquist