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]
* If Tomcat jdbc is available and the driverClassName and url
are provided or can be guessed (e.g. for HSQL) it is used.
Properties spring.database.{driverClassName,url} are consulted.
* If Commons DBCP is available it is used (if Tomcat is not)
* Otherwise an EmbeddedDatabase is created if all the bits are
available
* A JdbcOperations and a NamedParameterJdbcOperations are
available by default if a DataSource is created
* The data source is initialized from spring.database.schema (csv
of resource patterns)
[Fixes#49393511]
Dave Syer
Phillip Webb
Greg Turnquist