Merge branch '1.1.x'

Conflicts:
	spring-boot-docs/src/main/asciidoc/howto.adoc
This commit is contained in:
Phillip Webb 2014-09-15 11:37:50 -07:00
commit 565e449d89
6 changed files with 32 additions and 11 deletions

View File

@ -21,6 +21,8 @@ import org.junit.Test;
import static org.junit.Assert.assertTrue;
/**
* Tests for {@link SpringBootWebSecurityConfiguration}.
*
* @author Dave Syer
*/
public class SpringBootWebSecurityConfigurationTests {

View File

@ -244,6 +244,9 @@ content into your application; rather pick only the properties that you need.
liquibase.default-schema= # default database schema to use
liquibase.drop-first=false
liquibase.enabled=true
liquibase.url= # specific JDBC url (if not set the default datasource is used)
liquibase.user= # user name for liquibase.url
liquibase.password= # password for liquibase.url
# JMX
spring.jmx.enabled=true # Expose MBeans from Spring

View File

@ -1364,6 +1364,25 @@ You will get the best results if you put this in a nested class, or a standalone
order of instantiation). The {github-code}/spring-boot-samples/spring-boot-sample-web-secure[secure web sample]
is a useful template to follow.
If you experience instantiation issues (e.g. using JDBC or JPA for the user detail store)
it might be worth extracting the `AuthenticationManagerBuilder` callback into a
`GlobalAuthenticationConfigurerAdapter` (in the `init()` method so it happens before the
authentication manager is needed elsewhere), e.g.
[source,java,indent=0,subs="verbatim,quotes,attributes"]
----
@Configuration
public class AuthenticationManagerConfiguration extends
GlobalAuthenticationConfigurerAdapter {
@Override
public void init(AuthenticationManagerBuilder auth) {
auth.inMemoryAuthentication() // ... etc.
}
}
----
[[howto-enable-https]]

View File

@ -199,9 +199,9 @@ exposed. For example, you could add the following to your `application.propertie
[[production-ready-application-info-automatic-expansion]]
==== Automatically expand info properties at build time
Rather than hardcoding some properties that are also specified in your project's
build configuration, you can automatically expand info properties using the
existing build configuration instead. This is possible in both Maven and Gradle.
Rather than hardcoding some properties that are also specified in your project's build
configuration, you can automatically expand info properties using the existing build
configuration instead. This is possible in both Maven and Gradle.
@ -246,9 +246,9 @@ the Java plugin's `processResources` task to do so:
[source,groovy,indent=0]
----
processResources {
expand(project.properties)
}
processResources {
expand(project.properties)
}
----
You can then refer to your Gradle project's properties via placeholders, e.g.

View File

@ -369,7 +369,7 @@ For example, the following YAML document:
[source,yaml,indent=0]
----
environments:
dev:
dev:`
url: http://dev.bar.com
name: Developer Setup
prod:

View File

@ -78,10 +78,7 @@ public class RunPluginFeatures implements PluginFeatures {
if (project.hasProperty("applicationDefaultJvmArgs")) {
return project.property("applicationDefaultJvmArgs");
}
else {
return Collections.emptyList();
}
return Collections.emptyList();
}
});
}