Merge branch '1.1.x'
Conflicts: spring-boot-docs/src/main/asciidoc/howto.adoc
This commit is contained in:
commit
565e449d89
|
@ -21,6 +21,8 @@ import org.junit.Test;
|
|||
import static org.junit.Assert.assertTrue;
|
||||
|
||||
/**
|
||||
* Tests for {@link SpringBootWebSecurityConfiguration}.
|
||||
*
|
||||
* @author Dave Syer
|
||||
*/
|
||||
public class SpringBootWebSecurityConfigurationTests {
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -78,10 +78,7 @@ public class RunPluginFeatures implements PluginFeatures {
|
|||
if (project.hasProperty("applicationDefaultJvmArgs")) {
|
||||
return project.property("applicationDefaultJvmArgs");
|
||||
}
|
||||
else {
|
||||
return Collections.emptyList();
|
||||
}
|
||||
|
||||
return Collections.emptyList();
|
||||
}
|
||||
});
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue