spring.oauth2.client.* properties are bound to an instance
of AuthorizationCodeResourceDetails so all its properties can be specified.
diff --git a/spring-cloud.html b/spring-cloud.html index 23eda7f..356162d 100644 --- a/spring-cloud.html +++ b/spring-cloud.html @@ -484,6 +484,7 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b
If you are using AMQP there needs to be a ConnectionFactory (from
+Spring Rabbit) in the application context. If there is a single
+ConnectionFactory it will be used, or if there is a one qualified as
+@HystrixConnectionFactory (on the client) and
+@TurbineConnectionFactory (on the server) it will be preferred over
+others, otherwise the @Primary one will be used. If there are
+multiple unqualified connection factories there will be an error.
Note that Spring Boot (as of 1.2.2) creates a ConnectionFactory that
+is not @Primary, so if you want to use one connection factory for
+the bus and another for business messages, you need to create both,
+and annotate them @*ConnectionFactory and @Primary respectively.
If you are using AMQP there needs to be a ConnectionFactory (from
+Spring Rabbit) in the application context. If there is a single
+ConnectionFactory it will be used, or if there is a one qualified as
+@BusConnectionFactory it will be preferred over others, otherwise
+the @Primary one will be used. If there are multiple unqualified
+connection factories there will be an error.
Note that Spring Boot (as of 1.2.2) creates a ConnectionFactory that
+is not @Primary, so if you want to use one connection factory for
+the bus and another for business messages, you need to create both,
+and annotate them @BusConnectionFactory and @Primary respectively.
spring.oauth2.client.* properties are bound to an instance
of AuthorizationCodeResourceDetails so all its properties can be specified.
The SSO (and Resource Server) features use an OAuth2RestTemplate
+internally to fetch user details for authentication. This is provided
+as a qualified @Bean with id "userInfoRestTemplate", but you
+shouldn’t need to know that to just use it. The default should be fine
+for most providers, but occasionally you might need to add additional
+interceptors, or change the request authenticator (which is how the
+token gets attached to outgoing requests). To add a customization just
+create a bean of type UserInfoRestTemplateCustomizer - it has a
+single method that will be called after the bean is created but before
+it is initialized. The rest template that is being customized here is
+only used internally to carry out authentication (in the SSO or
+Resource Server use cases).
A second {@link OAuth2RestTemplate} is available for autowiring if you +want to use it for back channel calls, and if there is a +token-authenticated user (in a web application) it will have the token +injected for you.
+