diff --git a/Edgware.SR3/images/sts_exception.png b/Edgware.SR3/images/sts_exception.png new file mode 100644 index 00000000..8607c38a Binary files /dev/null and b/Edgware.SR3/images/sts_exception.png differ diff --git a/Edgware.SR3/images/web-selected.png b/Edgware.SR3/images/web-selected.png new file mode 100644 index 00000000..aa6b2da6 Binary files /dev/null and b/Edgware.SR3/images/web-selected.png differ diff --git a/Edgware.SR3/index.html b/Edgware.SR3/index.html index 161fa28b..7bcb249b 100644 --- a/Edgware.SR3/index.html +++ b/Edgware.SR3/index.html @@ -90,7 +90,7 @@ $(addBlockSwitches);
-

2.0.0.BUILD-SNAPSHOT

+

1.3.8.RELEASE

diff --git a/Edgware.SR3/multi/images/sts_exception.png b/Edgware.SR3/multi/images/sts_exception.png new file mode 100644 index 00000000..8607c38a Binary files /dev/null and b/Edgware.SR3/multi/images/sts_exception.png differ diff --git a/Edgware.SR3/multi/images/web-selected.png b/Edgware.SR3/multi/images/web-selected.png new file mode 100644 index 00000000..aa6b2da6 Binary files /dev/null and b/Edgware.SR3/multi/images/web-selected.png differ diff --git a/Edgware.SR3/multi/multi__appendix_compendium_of_configuration_properties.html b/Edgware.SR3/multi/multi__appendix_compendium_of_configuration_properties.html index 4f70fe2a..f64f728f 100644 --- a/Edgware.SR3/multi/multi__appendix_compendium_of_configuration_properties.html +++ b/Edgware.SR3/multi/multi__appendix_compendium_of_configuration_properties.html @@ -1,6 +1,6 @@ - Part XV. Appendix: Compendium of Configuration Properties
Part XV. Appendix: Compendium of Configuration Properties
Prev   

Part XV. Appendix: Compendium of Configuration Properties

NameDefaultDescription

encrypt.fail-on-error

true

Flag to say that a process should fail if there is an encryption or decryption + Part XIV. Appendix: Compendium of Configuration Properties

Part XIV. Appendix: Compendium of Configuration Properties
Prev   

Part XIV. Appendix: Compendium of Configuration Properties

NameDefaultDescription

encrypt.fail-on-error

true

Flag to say that a process should fail if there is an encryption or decryption error.

encrypt.key

 

A symmetric key. As a stronger alternative consider using a keystore.

encrypt.key-store.alias

 

Alias for a key in the store.

encrypt.key-store.location

 

Location of the key store file, e.g. classpath:/keystore.jks.

encrypt.key-store.password

 

Password that locks the keystore.

encrypt.key-store.secret

 

Secret protecting the key (defaults to the same as the password).

encrypt.rsa.algorithm

 

The RSA algorithm to use (DEFAULT or OEAP). Once it is set do not change it (or existing ciphers will not a decryptable).

encrypt.rsa.salt

deadbeef

Salt for the random secret used to encrypt cipher text. Once it is set do not change it (or existing ciphers will not a decryptable).

encrypt.rsa.strong

false

Flag to indicate that "strong" AES encryption should be used internally. If @@ -264,4 +264,4 @@ proxy, so they are sharing authentication data. If using a physical URL outside your own domain, then generally it would be a bad idea to leak user credentials.

zuul.servlet-path

/zuul

Path to install Zuul as a servlet (not part of Spring MVC). The servlet is more memory efficient for requests with large bodies, e.g. file uploads.

zuul.ssl-hostname-validation-enabled

true

Flag to say whether the hostname for ssl connections should be verified or not. Default is true. - This should only be used in test setups!

zuul.strip-prefix

true

Flag saying whether to strip the prefix from the path before forwarding.

zuul.trace-request-body

true

Flag to say that request bodies can be traced.

Prev   
106. Lease lifecycle management (renewal and revocation) Home 
\ No newline at end of file + This should only be used in test setups!

zuul.strip-prefix

true

Flag saying whether to strip the prefix from the path before forwarding.

zuul.trace-request-body

true

Flag to say that request bodies can be traced.

Prev   
102. Lease lifecycle management (renewal and revocation) Home 
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__client_side_usage_2.html b/Edgware.SR3/multi/multi__client_side_usage_2.html index 2fb93c50..15789d88 100644 --- a/Edgware.SR3/multi/multi__client_side_usage_2.html +++ b/Edgware.SR3/multi/multi__client_side_usage_2.html @@ -1,8 +1,8 @@ - 98. Client Side Usage
98. Client Side Usage
Prev Part XIV. Spring Cloud Vault Next

98. Client Side Usage

To use these features in an application, just build it as a Spring + 94. Client Side Usage

94. Client Side Usage
Prev Part XIII. Spring Cloud Vault Next

94. Client Side Usage

To use these features in an application, just build it as a Spring Boot application that depends on spring-cloud-vault-config (e.g. see -the test cases). Example Maven configuration:

Example 98.1. pom.xml

<parent>
+the test cases). Example Maven configuration:
Example 94.1. pom.xml
<parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
     <version>1.5.4.RELEASE</version>
@@ -13,7 +13,7 @@ the test cases). Example Maven configuration:
<dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-vault-config</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
@@ -47,7 +47,7 @@ the test cases). Example Maven configuration:
8200 if it is running. To modify
 the startup behavior you can change the location of the Vault server
 using bootstrap.properties (like application.properties but for
-the bootstrap phase of an application context), e.g.
Example 98.2. bootstrap.yml
spring.cloud.vault:
+the bootstrap phase of an application context), e.g.
Example 94.2. bootstrap.yml
spring.cloud.vault:
     host: localhost
     port: 8200
     scheme: https
@@ -63,5 +63,5 @@ additional configuration like
 SSL and
 authentication.
If the application imports the spring-boot-starter-actuator project, the
 status of the vault server will be available via the /health endpoint.
The vault health indicator can be enabled or disabled through the
-property health.vault.enabled (default true).
98.1 Authentication
Vault requires an authentication mechanism to authorize client requests.
Spring Cloud Vault supports multiple authentication mechanisms to authenticate applications with Vault.
For a quickstart, use the root token printed by the Vault initialization.
Example 98.3. bootstrap.yml
spring.cloud.vault:
-    token: 19aefa97-cccc-bbbb-aaaa-225940e63d76

[Warning]Warning
Consider carefully your security requirements. Static token authentication is fine if you want quickly get started with Vault, but a static token is not protected any further. Any disclosure to unintended parties allows Vault use with the associated token roles.
Prev Up Next
97. Quick Start Home 99. Authentication methods

\ No newline at end of file
+property health.vault.enabled (default true).
94.1 Authentication
Vault requires an authentication mechanism to authorize client requests.
Spring Cloud Vault supports multiple authentication mechanisms to authenticate applications with Vault.
For a quickstart, use the root token printed by the Vault initialization.
Example 94.3. bootstrap.yml
spring.cloud.vault:
+    token: 19aefa97-cccc-bbbb-aaaa-225940e63d76

[Warning]Warning
Consider carefully your security requirements. Static token authentication is fine if you want quickly get started with Vault, but a static token is not protected any further. Any disclosure to unintended parties allows Vault use with the associated token roles.
Prev Up Next
93. Quick Start Home 95. Authentication methods

\ No newline at end of file
diff --git a/Edgware.SR3/multi/multi__configuring_authentication_downstream_of_a_zuul_proxy.html b/Edgware.SR3/multi/multi__configuring_authentication_downstream_of_a_zuul_proxy.html
index 72648888..bcea4482 100644
--- a/Edgware.SR3/multi/multi__configuring_authentication_downstream_of_a_zuul_proxy.html
+++ b/Edgware.SR3/multi/multi__configuring_authentication_downstream_of_a_zuul_proxy.html
@@ -1,6 +1,6 @@
 
       
-   81. Configuring Authentication Downstream of a Zuul Proxy
81. Configuring Authentication Downstream of a Zuul Proxy
Prev Part XI. Spring Cloud Security Next
81. Configuring Authentication Downstream of a Zuul Proxy
You can control the authorization behaviour downstream of an
+   77. Configuring Authentication Downstream of a Zuul Proxy
77. Configuring Authentication Downstream of a Zuul Proxy
Prev Part X. Spring Cloud Security Next
77. Configuring Authentication Downstream of a Zuul Proxy
You can control the authorization behaviour downstream of an
 @EnableZuulProxy through the proxy.auth.* settings. Example:
application.yml. 
 
proxy:
   auth:
@@ -14,4 +14,4 @@ just passed downstream), and the "recommendations" service has its
 authorization header removed. The default behaviour is to do a token
 relay if there is a token available, and passthru otherwise.
See
 
-ProxyAuthenticationProperties for full details.
Prev Up Next
80. More Detail Home Part XII. Spring Cloud for Cloud Foundry

\ No newline at end of file
+ProxyAuthenticationProperties for full details.
Prev Up Next
76. More Detail Home Part XI. Spring Cloud for Cloud Foundry

\ No newline at end of file
diff --git a/Edgware.SR3/multi/multi__contract_dsl.html b/Edgware.SR3/multi/multi__contract_dsl.html
index 10e5efdc..8fa3ceeb 100644
--- a/Edgware.SR3/multi/multi__contract_dsl.html
+++ b/Edgware.SR3/multi/multi__contract_dsl.html
@@ -1,6 +1,6 @@
 
       
-   91. Contract DSL
91. Contract DSL
Prev Part XIII. Spring Cloud Contract Next
91. Contract DSL
Spring Cloud Contract supports out of the box 2 types of DSL. One written in
+   87. Contract DSL
87. Contract DSL
Prev Part XII. Spring Cloud Contract Next
87. Contract DSL
Spring Cloud Contract supports out of the box 2 types of DSL. One written in
 Groovy and one written in YAML.
If you decide to write the contract in Groovy, do not be alarmed if you have not used Groovy
 before. Knowledge of the language is not really needed, as the Contract DSL uses only a
 tiny subset of it (only literals, method calls and closures). Also, the DSL is statically
@@ -94,13 +94,13 @@ response:
         regex: bar
       - key: foo3
         command: andMeToo($it)
[Tip]Tip
You can compile contracts to stubs mapping using standalone maven command:
-mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
91.1 Limitations
[Warning]Warning
Spring Cloud Contract Verifier does not properly support XML. Please use JSON or
+mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
87.1 Limitations
[Warning]Warning
Spring Cloud Contract Verifier does not properly support XML. Please use JSON or
 help us implement this feature.
[Warning]Warning
The support for verifying the size of JSON arrays is experimental. If you want
 to turn it on, please set the value of the following system property to true:
 spring.cloud.contract.verifier.assert.size. By default, this feature is set to false.
 You can also provide the assertJsonSize property in the plugin configuration.
[Warning]Warning
Because JSON structure can have any form, it can be impossible to parse it
 properly when using the Groovy DSL and the value(consumer(…​), producer(…​)) notation in GString. That
-is why you should use the Groovy Map notation.
91.2 Common Top-Level elements
The following sections describe the most common top-level elements:
91.2.1 Description
You can add a description to your contract. The description is arbitrary text. The
+is why you should use the Groovy Map notation.
87.2 Common Top-Level elements
The following sections describe the most common top-level elements:
87.2.1 Description
You can add a description to your contract. The description is arbitrary text. The
 following code shows an example:
Groovy DSL. 
 
		org.springframework.cloud.contract.spec.Contract.make {
 			description('''
@@ -158,7 +158,7 @@ response:
         regex: bar
       - key: foo3
         command: andMeToo($it)

-
91.2.2 Name
You can provide a name for your contract. Assume that you provided the following name:
+
87.2.2 Name
You can provide a name for your contract. Assume that you provided the following name:
 should register a user. If you do so, the name of the autogenerated test is
 validate_should_register_a_user. Also, the name of the stub in a WireMock stub is
 should_register_a_user.json.
[Important]Important
You must ensure that the name does not contain any characters that make the
@@ -170,14 +170,14 @@ override each other.
Groovy DSL. 
 }

 
YAML. 
 
name: some name

-
91.2.3 Ignoring Contracts
If you want to ignore a contract, you can either set a value of ignored contracts in the
+
87.2.3 Ignoring Contracts
If you want to ignore a contract, you can either set a value of ignored contracts in the
 plugin configuration or set the ignored property on the contract itself:
Groovy DSL. 
 
org.springframework.cloud.contract.spec.Contract.make {
 	ignored()
 }

 
YAML. 
 
ignored: true

-
91.2.4 Passing Values from Files
Starting with version 1.2.0, you can pass values from files. Assume that you have the
+
87.2.4 Passing Values from Files
Starting with version 1.2.0, you can pass values from files. Assume that you have the
 following resources in our project.
└── src
     └── test
         └── resources
@@ -214,7 +214,7 @@ response:
   bodyFromFile: response.json

 
Further assume that the JSON files is as follows:
request.json
{ "status" : "REQUEST" }
response.json
{ "status" : "RESPONSE" }
When test or stub generation takes place, the contents of the file is passed to the body
 of a request or a response. The name of the file needs to be a file with location
-relative to the folder in which the contract lays.
91.2.5 HTTP Top-Level Elements
The following methods can be called in the top-level closure of a contract definition.
+relative to the folder in which the contract lays.
87.2.5 HTTP Top-Level Elements
The following methods can be called in the top-level closure of a contract definition.
 request and response are mandatory. priority is optional.
Groovy DSL. 
 
org.springframework.cloud.contract.spec.Contract.make {
 	// Definition of HTTP request part of the contract
@@ -244,7 +244,7 @@ response:
 ...

 
[Important]Important
If you want to make your contract have a higher value of priority
 you need to pass a lower number to the priority tag / method. E.g. priority with
-value 5 has higher priority than priority with value 10.
91.3 Request
The HTTP protocol requires only method and url to be specified in a request. The
+value 5 has higher priority than priority with value 10.

87.3 Request

The HTTP protocol requires only method and url to be specified in a request. The same information is mandatory in request definition of the Contract.

Groovy DSL.  

org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -509,7 +509,7 @@ parametrization of either fileName or "transformers" : [ "response-template", "foo-transformer" ]
   }
 }
-	'''

91.4 Response

The response must contain an HTTP status code and may contain other information. The + '''

87.4 Response

The response must contain an HTTP status code and may contain other information. The following code shows an example:

Groovy DSL.  

org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -526,12 +526,12 @@ following code shows an example:
Groovy DSL. 
 ...
 status: 200

Besides status, the response may contain headers and a body, both of which are -specified the same way as in the request (see the previous paragraph).

91.5 Dynamic properties

The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not +specified the same way as in the request (see the previous paragraph).

87.5 Dynamic properties

The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not want to force the consumers to stub their clocks to always return the same value of time so that it gets matched by the stub.

For Groovy DSL you can provide the dynamic parts in your contracts in two ways: pass them directly in the body or set them in separate sections called -testMatchers and stubMatchers.

For YAML you can only use the matchers section.

91.5.1 Dynamic properties inside the body

[Important]Important

This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can set the properties inside the body either with the value method or, if you use +testMatchers and stubMatchers.

For YAML you can only use the matchers section.

87.5.1 Dynamic properties inside the body

[Important]Important

This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can set the properties inside the body either with the value method or, if you use the Groovy map notation, with $(). The following example shows how to set dynamic properties with the value method:

value(consumer(...), producer(...))
 value(c(...), p(...))
@@ -540,8 +540,8 @@ value(client(...), server(...))

The following example shows how to set d $(c(...), p(...)) $(stub(...), test(...)) $(client(...), server(...))

Both approaches work equally well. stub and client methods are aliases over the consumer -method. Subsequent sections take a closer look at what you can do with those values.

91.5.2 Regular expressions

[Important]Important

This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can use regular expressions to write your requests in Contract DSL. Doing so is +method. Subsequent sections take a closer look at what you can do with those values.

87.5.2 Regular expressions

[Important]Important

This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can use regular expressions to write your requests in Contract DSL. Doing so is particularly useful when you want to indicate that a given response should be provided for requests that follow a given pattern. Also, you can use regular expressions when you need to use patterns and not exact values both for your test and your server side tests.

The following example shows how to use regular expressions to write a request:

org.springframework.cloud.contract.spec.Contract.make {
@@ -687,8 +687,8 @@ String nonBlank() {
 				message: "User not found by email = [${value(producer(regex(email())), consumer('not.existing@user.com'))}]"
 		)
 	}
-}

91.5.3 Passing Optional Parameters

[Important]Important

This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

It is possible to provide optional parameters in your contract. However, you can provide +}

87.5.3 Passing Optional Parameters

[Important]Important

This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

It is possible to provide optional parameters in your contract. However, you can provide optional parameters only for the following:

  • STUB side of the Request
  • TEST side of the Response

The following example shows how to provide optional parameters:

org.springframework.cloud.contract.spec.Contract.make {
 	priority 1
 	request {
@@ -753,8 +753,8 @@ expression that must be present 0 or more times.
If you use Spock for, the
   },
   "priority" : 1
 }
-'''

91.5.4 Executing Custom Methods on the Server Side

[Important]Important

This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can define a method call that executes on the server side during the test. Such a +'''

87.5.4 Executing Custom Methods on the Server Side

[Important]Important

This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

You can define a method call that executes on the server side during the test. Such a method can be added to the class defined as "baseClassForTests" in the configuration. The following code shows an example of the contract portion of the test case:

org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -817,7 +817,7 @@ It should resemble the following code:
"/something");
 
 // then:
- assertThat(response.statusCode()).isEqualTo(200);

91.5.5 Referencing the Request from the Response

The best situation is to provide fixed values, but sometimes you need to reference a + assertThat(response.statusCode()).isEqualTo(200);

87.5.5 Referencing the Request from the Response

The best situation is to provide fixed values, but sometimes you need to reference a request in your response.

If you’re writing contracts using Groovy DSL, you can use the fromRequest() method, which lets you reference a bunch of elements from the HTTP request. You can use the following options:

  • fromRequest().url(): Returns the request URL and query parameters.
  • fromRequest().query(String key): Returns the first query parameter with a given name.
  • fromRequest().query(String key, int index): Returns the nth query parameter with a @@ -965,7 +965,7 @@ in sending the following response body:

    }
    [Important]Important

    This feature works only with WireMock having a version greater than or equal to 2.5.1. The Spring Cloud Contract Verifier uses WireMock’s response-template response transformer. It uses Handlebars to convert the Mustache {{{ }}} templates into -proper values. Additionally, it registers two helper functions:

    • escapejsonbody: Escapes the request body in a format that can be embedded in a JSON.
    • jsonpath: For a given parameter, find an object in the request body.

91.5.6 Registering Your Own WireMock Extension

WireMock lets you register custom extensions. By default, Spring Cloud Contract registers +proper values. Additionally, it registers two helper functions:

  • escapejsonbody: Escapes the request body in a format that can be embedded in a JSON.
  • jsonpath: For a given parameter, find an object in the request body.

87.5.6 Registering Your Own WireMock Extension

WireMock lets you register custom extensions. By default, Spring Cloud Contract registers the transformer, which lets you reference a request from a response. If you want to provide your own extensions, you can register an implementation of the org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions interface. @@ -997,7 +997,7 @@ org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExte } }

[Important]Important

Remember to override the applyGlobally() method and set it to false if you -want the transformation to be applied only for a mapping that explicitly requires it.

91.5.7 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. +want the transformation to be applied only for a mapping that explicitly requires it.

87.5.7 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. Quite a few users are used to having a separation between the body and setting the dynamic parts of a contract.

You can use two separate sections:

  • stubMatchers, which lets you define the dynamic values that should end up in a stub. You can set it in the request or inputMessage part of your contract.
  • testMatchers, which is present in the response or outputMessage side of the @@ -1402,7 +1402,7 @@ and: assertThat(parsedJson.read("\$.events[0].eventId", String.class)).matches("^([a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})\$") assertThat(parsedJson.read("\$.events[0].status", String.class)).matches(".+")

    As you can see, the assertion is malformed. Only the first element of the array got asserted. In order to fix this, you should apply the assertion to the whole $.events -collection and assert it with the byCommand(…​) method.

91.6 JAX-RS Support

The Spring Cloud Contract Verifier supports the JAX-RS 2 Client API. The base class needs +collection and assert it with the byCommand(…​) method.

87.6 JAX-RS Support

The Spring Cloud Contract Verifier supports the JAX-RS 2 Client API. The base class needs to define protected WebTarget webTarget and server initialization. The only option for testing JAX-RS API is to start a web server. Also, a request with a body needs to have a content type set. Otherwise, the default of application/octet-stream gets used.

In order to use JAX-RS mode, use the following settings:

testMode == 'JAXRSCLIENT'

The following example shows a generated test API:

'''
@@ -1427,7 +1427,7 @@ content type set. Otherwise, the default of application/oc
  // and:
   DocumentContext parsedJson = JsonPath.parse(responseAsString);
   assertThatJson(parsedJson).field("['property1']").isEqualTo("a");
-'''

91.7 Async Support

If you’re using asynchronous communication on the server side (your controllers are +'''

87.7 Async Support

If you’re using asynchronous communication on the server side (your controllers are returning Callable, DeferredResult, and so on), then, inside your contract, you must provide a sync() method in the response section. The following code shows an example:

Groovy DSL.  

org.springframework.cloud.contract.spec.Contract.make {
@@ -1444,7 +1444,7 @@ provide a sync() method in the response:
     async: true

-

91.8 Working with Context Paths

Spring Cloud Contract supports context paths.

[Important]Important

The only change needed to fully support context paths is the switch on the +

87.8 Working with Context Paths

Spring Cloud Contract supports context paths.

[Important]Important

The only change needed to fully support context paths is the switch on the PRODUCER side. Also, the autogenerated tests must use EXPLICIT mode. The consumer side remains untouched. In order for the generated test to pass, you must use EXPLICIT mode.

Maven.  @@ -1488,8 +1488,8 @@ socket.

Consider the following contract:

or
 	}
 }

If you do it this way:

  • All of your requests in the autogenerated tests are sent to the real endpoint with your context path included (for example, /my-context-path/url).
  • Your contracts reflect that you have a context path. Your generated stubs also have -that information (for example, in the stubs, you have to call /my-context-path/url).

91.9 Messaging Top-Level Elements

The DSL for messaging looks a little bit different than the one that focuses on HTTP. The -following sections explain the differences:

91.9.1 Output Triggered by a Method

The output message can be triggered by calling a method (such as a Scheduler when a was +that information (for example, in the stubs, you have to call /my-context-path/url).

87.9 Messaging Top-Level Elements

The DSL for messaging looks a little bit different than the one that focuses on HTTP. The +following sections explain the differences:

87.9.1 Output Triggered by a Method

The output message can be triggered by calling a method (such as a Scheduler when a was started and a message was sent), as shown in the following example:

Groovy DSL.  

def dsl = Contract.make {
 	// Human readable description
@@ -1534,7 +1534,7 @@ outputMessage:
 
In the previous example case, the output message is sent to output if a method called
 bookReturnedTriggered is executed. On the message publisher’s side, we generate a
 test that calls that method to trigger the message. On the consumer side, you can use
-the some_label to trigger the message.

91.9.2 Output Triggered by a Message

The output message can be triggered by receiving a message, as shown in the following +the some_label to trigger the message.

87.9.2 Output Triggered by a Message

The output message can be triggered by receiving a message, as shown in the following example:

Groovy DSL.  

def dsl = Contract.make {
 	description 'Some Description'
@@ -1590,7 +1590,7 @@ outputMessage:
 received on the input destination. On the message publisher’s side, the engine
 generates a test that sends the input message to the defined destination. On the
 consumer side, you can either send a message to the input destination or use a label
-(some_label in the example) to trigger the message.

91.9.3 Consumer/Producer

[Important]Important

This section is valid only for Groovy DSL.

In HTTP, you have a notion of client/stub and `server/test notation. You can also +(some_label in the example) to trigger the message.

87.9.3 Consumer/Producer

[Important]Important

This section is valid only for Groovy DSL.

In HTTP, you have a notion of client/stub and `server/test notation. You can also use those paradigms in messaging. In addition, Spring Cloud Contract Verifier also provides the consumer and producer methods, as presented in the following example (note that you can use either $ or value methods to provide consumer and producer @@ -1611,10 +1611,10 @@ parts):

Contract.make {
 				bookName: 'foo'
 		])
 	}
-}

91.9.4 Common

In the input or outputMessage section you can call assertThat with the name +}

87.9.4 Common

In the input or outputMessage section you can call assertThat with the name of a method (e.g. assertThatMessageIsOnTheQueue()) that you have defined in the base class or in a static import. Spring Cloud Contract will execute that method -in the generated test.

91.10 Multiple Contracts in One File

You can define multiple contracts in one file. Such a contract might resemble the +in the generated test.

87.10 Multiple Contracts in One File

You can define multiple contracts in one file. Such a contract might resemble the following example:

Groovy DSL.  

import org.springframework.cloud.contract.spec.Contract
 
@@ -1703,4 +1703,4 @@ index of the contract in the list.
The generated stubs is shown in the fol
 1_WithList.json

As you can see, the first file got the name parameter from the contract. The second got the name of the contract file (WithList.groovy) prefixed with the index (in this case, the contract had an index of 1 in the list of contracts in the file).

[Tip]Tip

As you can see, it iss much better if you name your contracts because doing so makes -your tests far more meaningful.

Prev Up Next
90. Stub Runner for Messaging Home 92. Customization
\ No newline at end of file +your tests far more meaningful.

Prev Up Next
86. Stub Runner for Messaging Home 88. Customization
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__customization.html b/Edgware.SR3/multi/multi__customization.html index 19cc8264..bdf36f2a 100644 --- a/Edgware.SR3/multi/multi__customization.html +++ b/Edgware.SR3/multi/multi__customization.html @@ -1,9 +1,9 @@ - 92. Customization
92. Customization
Prev Part XIII. Spring Cloud Contract Next

92. Customization

[Important]Important

This section is valid only for Groovy DSL

You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in -the remainder of this section.

92.1 Extending the DSL

You can provide your own functions to the DSL. The key requirement for this feature is to + 88. Customization

88. Customization
Prev Part XII. Spring Cloud Contract Next

88. Customization

[Important]Important

This section is valid only for Groovy DSL

You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in +the remainder of this section.

88.1 Extending the DSL

You can provide your own functions to the DSL. The key requirement for this feature is to maintain the static compatibility. Later in this document, you can see examples of:

  • Creating a JAR with reusable classes.
  • Referencing of these classes in the DSLs.

You can find the full example -here.

92.1.1 Common JAR

The following examples show three classes that can be reused in the DSLs.

PatternUtils contains functions used by both the consumer and the producer.

package com.example;
+here.
88.1.1 Common JAR
The following examples show three classes that can be reused in the DSLs.
PatternUtils contains functions used by both the consumer and the producer.
package com.example;
 
 import java.util.regex.Pattern;
 
@@ -134,8 +134,8 @@ maintain the static compatibility. Later in this document, you can see examples
 		return new ServerDslProperty( PatternUtils.ok(), "OK");
 	}
 }
-//end::impl[]
92.1.2 Adding the Dependency to the Project
In order for the plugins and IDE to be able to reference the common JAR classes, you need
-to pass the dependency to your project.
92.1.3 Test the Dependency in the Project’s Dependencies
First, add the common jar dependency as a test dependency. Because your contracts files
+//end::impl[]

88.1.2 Adding the Dependency to the Project

In order for the plugins and IDE to be able to reference the common JAR classes, you need +to pass the dependency to your project.

88.1.3 Test the Dependency in the Project’s Dependencies

First, add the common jar dependency as a test dependency. Because your contracts files are available on the test resources path, the common jar classes automatically become visible in your Groovy files. The following examples show how to test the dependency:

Maven.  

<dependency>
@@ -146,7 +146,7 @@ visible in your Groovy files. The following examples show how to test the depend
 </dependency>

Gradle.  

testCompile("com.example:beer-common:0.0.1-SNAPSHOT")

-

92.1.4 Test a Dependency in the Plugin’s Dependencies

Now, you must add the dependency for the plugin to reuse at runtime, as shown in the +

88.1.4 Test a Dependency in the Plugin’s Dependencies

Now, you must add the dependency for the plugin to reuse at runtime, as shown in the following example:

Maven.  

<plugin>
 	<groupId>org.springframework.cloud</groupId>
@@ -173,7 +173,7 @@ following example:
Maven. 
 </plugin>

Gradle.  

classpath "com.example:beer-common:0.0.1-SNAPSHOT"

-

92.1.5 Referencing classes in DSLs

You can now reference your classes in your DSL, as shown in the following example:

package contracts.beer.rest
+

88.1.5 Referencing classes in DSLs

You can now reference your classes in your DSL, as shown in the following example:

package contracts.beer.rest
 
 import com.example.ConsumerUtils
 import com.example.ProducerUtils
@@ -214,4 +214,4 @@ then:
 			contentType(applicationJson())
 		}
 	}
-}
Prev Up Next
91. Contract DSL Home 93. Using the Pluggable Architecture
\ No newline at end of file +}
Prev Up Next
87. Contract DSL Home 89. Using the Pluggable Architecture
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__discovery.html b/Edgware.SR3/multi/multi__discovery.html index a18e88be..86707cc9 100644 --- a/Edgware.SR3/multi/multi__discovery.html +++ b/Edgware.SR3/multi/multi__discovery.html @@ -1,6 +1,6 @@ - 82. Discovery
82. Discovery
Prev Part XII. Spring Cloud for Cloud Foundry Next

82. Discovery

Here’s a Spring Cloud app with Cloud Foundry discovery:

app.groovy.  + 78. Discovery

78. Discovery
Prev Part XI. Spring Cloud for Cloud Foundry Next

78. Discovery

Here’s a Spring Cloud app with Cloud Foundry discovery:

app.groovy.  

@Grab('org.springframework.cloud:spring-cloud-cloudfoundry')
 @RestController
 @EnableDiscoveryClient
@@ -19,4 +19,4 @@
 $ cf push -p app.jar

It will show its app name in the home page.

The DiscoveryClient can lists all the apps in a space, according to the credentials it is authenticated with, where the space defaults to the one the client is running in (if any). If neither org nor space -are configured, they default per the user’s profile in Cloud Foundry.

Prev Up Next
Part XII. Spring Cloud for Cloud Foundry Home 83. Single Sign On
\ No newline at end of file +are configured, they default per the user’s profile in Cloud Foundry.

Prev Up Next
Part XI. Spring Cloud for Cloud Foundry Home 79. Single Sign On
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__links.html b/Edgware.SR3/multi/multi__links.html index 3b22e7b3..f571c53c 100644 --- a/Edgware.SR3/multi/multi__links.html +++ b/Edgware.SR3/multi/multi__links.html @@ -1,6 +1,6 @@ - 96. Links
96. Links
Prev Part XIII. Spring Cloud Contract Next

96. Links

The following links may be helpful when working with Spring Cloud Contract Verifier:

Prev Up Next
91. Migrations Home Part XIII. Spring Cloud Vault
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__migrations.html b/Edgware.SR3/multi/multi__migrations.html index 736bc3ff..2bb05c2d 100644 --- a/Edgware.SR3/multi/multi__migrations.html +++ b/Edgware.SR3/multi/multi__migrations.html @@ -1,7 +1,7 @@ - 95. Migrations
95. Migrations
Prev Part XIII. Spring Cloud Contract Next

95. Migrations

This section covers migrating from one version of Spring Cloud Contract Verifier to the -next version. It covers the following versions upgrade paths:

95.1 1.0.x → 1.1.x

This section covers upgrading from version 1.0 to version 1.1.

95.1.1 New structure of generated stubs

In 1.1.x we have introduced a change to the structure of generated stubs. If you have + 91. Migrations

91. Migrations
Prev Part XII. Spring Cloud Contract Next

91. Migrations

This section covers migrating from one version of Spring Cloud Contract Verifier to the +next version. It covers the following versions upgrade paths:

91.1 1.0.x → 1.1.x

This section covers upgrading from version 1.0 to version 1.1.

91.1.1 New structure of generated stubs

In 1.1.x we have introduced a change to the structure of generated stubs. If you have been using the @AutoConfigureWireMock notation to use the stubs from the classpath, it no longer works. The following example shows how the @AutoConfigureWireMock notation used to work:

@AutoConfigureWireMock(stubs = "classpath:/customer-stubs/mappings", port = 8084)

You must either change the location of the stubs to: @@ -79,17 +79,17 @@ structure presented in the previous snippet.

Maven.&nbs from "${project.buildDir}/resources/main/customer-stubs/META-INF/${project.group}/${project.name}/${project.version}" into "${project.buildDir}/resources/main/customer-stubs" }

-

95.2 1.1.x → 1.2.x

This section covers upgrading from version 1.1 to version 1.2.

95.2.1 Custom HttpServerStub

HttpServerStub includes a method that was not in version 1.1. The method is +

91.2 1.1.x → 1.2.x

This section covers upgrading from version 1.1 to version 1.2.

91.2.1 Custom HttpServerStub

HttpServerStub includes a method that was not in version 1.1. The method is String registeredMappings() If you have classes that implement HttpServerStub, you now have to implement the registeredMappings() method. It should return a String representing all mappings available in a single HttpServerStub.

See issue 355 for more -detail.

95.2.2 New packages for generated tests

The flow for setting the generated tests package name will look like this:

  • Set basePackageForTests
  • If basePackageForTests was not set, pick the package from baseClassForTests
  • If baseClassForTests was not set, pick packageWithBaseClasses
  • If nothing got set, pick the default value: +detail.

91.2.2 New packages for generated tests

The flow for setting the generated tests package name will look like this:

  • Set basePackageForTests
  • If basePackageForTests was not set, pick the package from baseClassForTests
  • If baseClassForTests was not set, pick packageWithBaseClasses
  • If nothing got set, pick the default value: org.springframework.cloud.contract.verifier.tests

See issue 260 for more -detail.

95.2.3 New Methods in TemplateProcessor

In order to add support for fromRequest.path, the following methods had to be added to the +detail.

91.2.3 New Methods in TemplateProcessor

In order to add support for fromRequest.path, the following methods had to be added to the TemplateProcessor interface:

  • path()
  • path(int index)

See issue 388 for more -detail.

95.2.4 RestAssured 3.0

Rest Assured, used in the generated test classes, got bumped to 3.0. If +detail.

91.2.4 RestAssured 3.0

Rest Assured, used in the generated test classes, got bumped to 3.0. If you manually set versions of Spring Cloud Contract and the release train you might see the following exception:

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project some-project: Compilation failure: Compilation failure:
 [ERROR] /some/path/SomeClass.java:[4,39] package com.jayway.restassured.response does not exist

This exception will occur due to the fact that the tests got generated with an old version of plugin and at test execution time you have an incompatible -version of the release train (and vice versa).

Done via issue 267

Prev Up Next
94. Spring Cloud Contract WireMock Home 96. Links
\ No newline at end of file +version of the release train (and vice versa).

Done via issue 267

Prev Up Next
90. Spring Cloud Contract WireMock Home 92. Links
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__more_detail.html b/Edgware.SR3/multi/multi__more_detail.html index 67b0f8ec..519d94c7 100644 --- a/Edgware.SR3/multi/multi__more_detail.html +++ b/Edgware.SR3/multi/multi__more_detail.html @@ -1,11 +1,11 @@ - 80. More Detail
80. More Detail
Prev Part XI. Spring Cloud Security Next

80. More Detail

80.1 Single Sign On

[Note]Note

All of the OAuth2 SSO and resource server features moved to Spring Boot + 76. More Detail

76. More Detail
Prev Part X. Spring Cloud Security Next

76. More Detail

76.1 Single Sign On

[Note]Note

All of the OAuth2 SSO and resource server features moved to Spring Boot in version 1.3. You can find documentation in the -Spring Boot user guide.

80.2 Token Relay

A Token Relay is where an OAuth2 consumer acts as a Client and +Spring Boot user guide.

76.2 Token Relay

A Token Relay is where an OAuth2 consumer acts as a Client and forwards the incoming token to outgoing resource requests. The consumer can be a pure Client (like an SSO application) or a Resource -Server.

80.2.1 Client Token Relay

If your app is a user facing OAuth2 client (i.e. has declared +Server.

76.2.1 Client Token Relay

If your app is a user facing OAuth2 client (i.e. has declared @EnableOAuth2Sso or @EnableOAuth2Client) then it has an OAuth2ClientContext in request scope from Spring Boot. You can create your own OAuth2RestTemplate from this context and an @@ -16,7 +16,7 @@ Security and Spring Boot.)

OAuth2ProtectedResourceDetails automatically if you are using client_credentials tokens. In that case you need to create your own ClientCredentialsResourceDetails and configure it with -@ConfigurationProperties("security.oauth2.client").

80.2.2 Client Token Relay in Zuul Proxy

If your app also has a +@ConfigurationProperties("security.oauth2.client").

76.2.2 Client Token Relay in Zuul Proxy

If your app also has a Spring Cloud Zuul embedded reverse proxy (using @EnableZuulProxy) then you can ask it to forward OAuth2 access tokens downstream to the services @@ -39,7 +39,7 @@ a ZuulFilter, which itself is activated because Zuu classpath (via @EnableZuulProxy). The filter just extracts an access token from the currently authenticated user, -and puts it in a request header for the downstream requests.

80.2.3 Resource Server Token Relay

If your app has @EnableResourceServer you might want to relay the +and puts it in a request header for the downstream requests.

76.2.3 Resource Server Token Relay

If your app has @EnableResourceServer you might want to relay the incoming token downstream to other services. If you use a RestTemplate to contact the downstream services then this is just a matter of how to create the template with the right context.

If your service uses UserInfoTokenServices to authenticate incoming @@ -81,4 +81,4 @@ choice, since you might want to act as yourself, rather than the client that sent you the token), then you only need to create your own OAuth2Context instead of autowiring the default one.

Feign clients will also pick up an interceptor that uses the OAuth2ClientContext if it is available, so they should also do a -token relay anywhere where a RestTemplate would.

Prev Up Next
79. Quickstart Home 81. Configuring Authentication Downstream of a Zuul Proxy
\ No newline at end of file +token relay anywhere where a RestTemplate would.

Prev Up Next
75. Quickstart Home 77. Configuring Authentication Downstream of a Zuul Proxy
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__quick_start_3.html b/Edgware.SR3/multi/multi__quick_start_3.html index bfb20255..04f05145 100644 --- a/Edgware.SR3/multi/multi__quick_start_3.html +++ b/Edgware.SR3/multi/multi__quick_start_3.html @@ -1,6 +1,6 @@ - 97. Quick Start
97. Quick Start
Prev Part XIV. Spring Cloud Vault Next

97. Quick Start

Prerequisites

To get started with Vault and this guide you need a + 93. Quick Start

93. Quick Start
Prev Part XIII. Spring Cloud Vault Next

93. Quick Start

Prerequisites

To get started with Vault and this guide you need a *NIX-like operating systems that provides:

  • wget, openssl and unzip
  • at least Java 7 and a properly configured JAVA_HOME environment variable

Install Vault

$ src/test/bash/install_vault.sh

Create SSL certificates for Vault

$ src/test/bash/create_certificates.sh
[Note]Note

create_certificates.sh creates certificates in work/ca and a JKS truststore work/keystore.jks. If you want to run Spring Cloud Vault using this quickstart guide you need to configure the truststore the spring.cloud.vault.ssl.trust-store property to file:work/keystore.jks.

Start Vault server

$ src/test/bash/local_run_vault.sh

Vault is started listening on 0.0.0.0:8200 using the inmem storage and https. Vault is sealed and not initialized when starting up.

[Note]Note

If you want to run tests, leave Vault uninitialized. The tests will @@ -34,4 +34,4 @@ backend is enabled which accesses secret config settings via JSON endpoints.

SpringApplication (i.e. what is normally "application" in a regular Spring Boot app), "profile" is an active profile (or comma-separated list of properties). Properties retrieved from Vault will be used "as-is" -without further prefixing of the property names.

Prev Up Next
Part XIV. Spring Cloud Vault Home 98. Client Side Usage
\ No newline at end of file +without further prefixing of the property names.

Prev Up Next
Part XIII. Spring Cloud Vault Home 94. Client Side Usage
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__quickstart.html b/Edgware.SR3/multi/multi__quickstart.html index fcb4b40d..9ce5cd81 100644 --- a/Edgware.SR3/multi/multi__quickstart.html +++ b/Edgware.SR3/multi/multi__quickstart.html @@ -1,6 +1,6 @@ - 79. Quickstart
79. Quickstart
Prev Part XI. Spring Cloud Security Next

79. Quickstart

79.1 OAuth2 Single Sign On

Here’s a Spring Cloud "Hello World" app with HTTP Basic + 75. Quickstart

75. Quickstart
Prev Part X. Spring Cloud Security Next

75. Quickstart

75.1 OAuth2 Single Sign On

Here’s a Spring Cloud "Hello World" app with HTTP Basic authentication and a single user account:

app.groovy.  

@Grab('spring-boot-starter-security')
 @Controller
@@ -50,7 +50,7 @@ decide what the defaults should be, usually depending on the settings in
 the client registration that it holds.
[Note]Note
The examples above are all Groovy scripts. If you want to write the
 same code in Java (or Groovy) you need to add Spring Security OAuth2
 to the classpath (e.g. see the
-sample here).

79.2 OAuth2 Protected Resource

You want to protect an API resource with an OAuth2 token? Here’s a +sample here).

75.2 OAuth2 Protected Resource

You want to protect an API resource with an OAuth2 token? Here’s a simple example (paired with the client above):

app.groovy.  

@Grab('spring-cloud-starter-security')
 @RestController
@@ -69,4 +69,4 @@ simple example (paired with the client above):
app.groovy. 
     resource:
       userInfoUri: https://api.github.com/user
       preferTokenInfo: false

-

Prev Up Next
Part XI. Spring Cloud Security Home 80. More Detail
\ No newline at end of file +

Prev Up Next
Part X. Spring Cloud Security Home 76. More Detail
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__service_registry_configuration.html b/Edgware.SR3/multi/multi__service_registry_configuration.html index 71cba465..f036f833 100644 --- a/Edgware.SR3/multi/multi__service_registry_configuration.html +++ b/Edgware.SR3/multi/multi__service_registry_configuration.html @@ -1,6 +1,6 @@ - 103. Service Registry Configuration
103. Service Registry Configuration
Prev Part XIV. Spring Cloud Vault Next

103. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate + 99. Service Registry Configuration

99. Service Registry Configuration
Prev Part XIII. Spring Cloud Vault Next

99. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate a Vault server by setting spring.cloud.vault.discovery.enabled=true (default false). The net result of that is that your apps need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration. @@ -14,4 +14,4 @@ need to provide a scheme metadata entry to be set e If no scheme is configured and the service is not exposed as secure service, then configuration defaults to spring.cloud.vault.scheme which is https when it’s not set.

spring.cloud.vault.discovery:
     enabled: true
-    service-id: my-vault-service
Prev Up Next
102. Configure PropertySourceLocator behavior Home 104. Vault Client Fail Fast
\ No newline at end of file + service-id: my-vault-service
Prev Up Next
98. Configure PropertySourceLocator behavior Home 100. Vault Client Fail Fast
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__single_sign_on_2.html b/Edgware.SR3/multi/multi__single_sign_on_2.html index 1aa0a147..5e891908 100644 --- a/Edgware.SR3/multi/multi__single_sign_on_2.html +++ b/Edgware.SR3/multi/multi__single_sign_on_2.html @@ -1,6 +1,6 @@ - 83. Single Sign On
83. Single Sign On
Prev Part XII. Spring Cloud for Cloud Foundry Next

83. Single Sign On

[Note]Note

All of the OAuth2 SSO and resource server features moved to Spring Boot + 79. Single Sign On

79. Single Sign On
Prev Part XI. Spring Cloud for Cloud Foundry Next

79. Single Sign On

[Note]Note

All of the OAuth2 SSO and resource server features moved to Spring Boot in version 1.3. You can find documentation in the Spring Boot user guide.

This project provides automatic binding from CloudFoundry service credentials to the Spring Boot features. If you have a CloudFoundry @@ -8,4 +8,4 @@ service called "sso", for instance, with credentials containing "client_id", "client_secret" and "auth_domain", it will bind automatically to the Spring OAuth2 client that you enable with @EnableOAuth2Sso (from Spring Boot). The name of the service can be -parameterized using spring.oauth2.sso.serviceId.

Prev Up Next
82. Discovery Home Part XIII. Spring Cloud Contract
\ No newline at end of file +parameterized using spring.oauth2.sso.serviceId.

Prev Up Next
78. Discovery Home Part XII. Spring Cloud Contract
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_config.html b/Edgware.SR3/multi/multi__spring_cloud_config.html index 2625f75d..2ea3f227 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_config.html +++ b/Edgware.SR3/multi/multi__spring_cloud_config.html @@ -1,3 +1,3 @@ - Part II. Spring Cloud Config
Part II. Spring Cloud Config
Prev   Next

Part II. Spring Cloud Config

2.0.0.BUILD-SNAPSHOT

Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

Prev   Next
3. Spring Cloud Commons: Common Abstractions Home 4. Quick Start
\ No newline at end of file + Part II. Spring Cloud Config
Part II. Spring Cloud Config
Prev   Next

Part II. Spring Cloud Config

1.3.8.RELEASE

Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

Prev   Next
3. Spring Cloud Commons: Common Abstractions Home 4. Quick Start
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_consul.html b/Edgware.SR3/multi/multi__spring_cloud_consul.html index f57557bc..2f67f582 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_consul.html +++ b/Edgware.SR3/multi/multi__spring_cloud_consul.html @@ -1,6 +1,6 @@ - Part VIII. Spring Cloud Consul
Part VIII. Spring Cloud Consul
Prev   Next

Part VIII. Spring Cloud Consul

2.0.0.BUILD-SNAPSHOT

This project provides Consul integrations for Spring Boot apps through autoconfiguration + Part VIII. Spring Cloud Consul

Part VIII. Spring Cloud Consul
Prev   Next

Part VIII. Spring Cloud Consul

1.3.8.RELEASE

This project provides Consul integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with Consul based components. The diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract.html b/Edgware.SR3/multi/multi__spring_cloud_contract.html index 51edbf04..81ab7781 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract.html @@ -1,4 +1,4 @@ - Part XIII. Spring Cloud Contract

Part XIII. Spring Cloud Contract
Prev   Next

Part XIII. Spring Cloud Contract

_Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, -Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

2.0.0.BUILD-SNAPSHOT

Prev   Next
83. Single Sign On Home 84. Spring Cloud Contract
\ No newline at end of file + Part XII. Spring Cloud Contract
Part XII. Spring Cloud Contract
Prev   Next

Part XII. Spring Cloud Contract

_Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, +Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

1.3.8.RELEASE

Prev   Next
79. Single Sign On Home 80. Spring Cloud Contract
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_2.html b/Edgware.SR3/multi/multi__spring_cloud_contract_2.html index f7183316..8838942e 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_2.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_2.html @@ -1,7 +1,7 @@ - 84. Spring Cloud Contract
84. Spring Cloud Contract
Prev Part XIII. Spring Cloud Contract Next

84. Spring Cloud Contract

You need confidence when pushing new features to a new application or service in a + 80. Spring Cloud Contract

80. Spring Cloud Contract
Prev Part XII. Spring Cloud Contract Next

80. Spring Cloud Contract

You need confidence when pushing new features to a new application or service in a distributed system. This project provides support for Consumer Driven Contracts and service schemas in Spring applications (for both HTTP and message-based interactions), covering a range of options for writing tests, publishing them as assets, and asserting -that a contract is kept by producers and consumers.

Prev Up Next
Part XIII. Spring Cloud Contract Home 85. Spring Cloud Contract Verifier Introduction
\ No newline at end of file +that a contract is kept by producers and consumers.

Prev Up Next
Part XII. Spring Cloud Contract Home 81. Spring Cloud Contract Verifier Introduction
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_faq.html b/Edgware.SR3/multi/multi__spring_cloud_contract_faq.html index b1c5b60d..c1d49fda 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_faq.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_faq.html @@ -1,8 +1,8 @@ - 86. Spring Cloud Contract FAQ
86. Spring Cloud Contract FAQ
Prev Part XIII. Spring Cloud Contract Next

86. Spring Cloud Contract FAQ

86.1 Why use Spring Cloud Contract Verifier and not X ?

For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating + 82. Spring Cloud Contract FAQ

82. Spring Cloud Contract FAQ
Prev Part XII. Spring Cloud Contract Next

82. Spring Cloud Contract FAQ

82.1 Why use Spring Cloud Contract Verifier and not X ?

For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make -Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

  • Possibility to do CDC with messaging
  • Clear and easy to use, statically typed DSL
  • Possibility to copy paste your current JSON file to the contract and only edit its elements
  • Automatic generation of tests from the defined Contract
  • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
  • Spring Cloud integration - no discovery service is needed for integration tests

86.2 I don’t want to write a contract in Groovy!

No problem. You can write a contract in YAML!

86.3 What is this value(consumer(), producer()) ?

One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. +Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

  • Possibility to do CDC with messaging
  • Clear and easy to use, statically typed DSL
  • Possibility to copy paste your current JSON file to the contract and only edit its elements
  • Automatic generation of tests from the defined Contract
  • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
  • Spring Cloud integration - no discovery service is needed for integration tests

82.2 I don’t want to write a contract in Groovy!

No problem. You can write a contract in YAML!

82.3 What is this value(consumer(), producer()) ?

One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. What typically makes that difficult are the hard-coded values of request / response elements. For example dates or ids. Imagine the following JSON request

{
     "time" : "2016-10-10 20:10:15",
@@ -68,19 +68,19 @@ for time and UUID are simplified and most likely invalid but we want to keep thi
 					])
 			}
 }
[Important]Important

Please read the Groovy docs related to JSON to understand how to -properly structure the request / response bodies.

86.4 How to do Stubs versioning?

86.4.1 API Versioning

Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are +properly structure the request / response bodies.

82.4 How to do Stubs versioning?

82.4.1 API Versioning

Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

  • use Hypermedia, links and do not version your API by any means
  • pass versions through headers / urls

I will not try to answer a question which approach is better. Whatever suit your needs and allows you to generate business value should be picked.

Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. -You can create a subfolder for every version or append it to th contract name - whatever suits you more.

86.4.2 JAR versioning

If by versioning you mean the version of the JAR that contains the stubs then there are essentially two main approaches.

Let’s assume that you’re doing Continuous Delivery / Deployment which means that you’re generating a new version of +You can create a subfolder for every version or append it to th contract name - whatever suits you more.

82.4.2 JAR versioning

If by versioning you mean the version of the JAR that contains the stubs then there are essentially two main approaches.

Let’s assume that you’re doing Continuous Delivery / Deployment which means that you’re generating a new version of the jar each time you go through the pipeline and that jar can go to production at any time. For example your jar version looks like this (it got built on the 20.10.2016 at 20:15:21) :

1.0.0.20161020-201521-RELEASE

In that case your generated stub jar will look like this.

1.0.0.20161020-201521-RELEASE-stubs.jar

In this case you should inside your application.yml or @AutoConfigureStubRunner when referencing stubs provide the latest version of the stubs. You can do that by passing the + sign. Example

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

If the versioning however is fixed (e.g. 1.0.4.RELEASE or 2.1.1) then you have to set the concrete value of the jar -version. Example for 2.1.1.

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})

86.4.3 Dev or prod stubs

You can manipulate the classifier to run the tests against current development version of the stubs of other services +version. Example for 2.1.1.

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})

82.4.3 Dev or prod stubs

You can manipulate the classifier to run the tests against current development version of the stubs of other services or the ones that were deployed to production. If you alter your build to deploy the stubs with the prod-stubs classifier - once you reach production deployment then you can run tests in one case with dev stubs and one with prod stubs.

Example of tests using development version of stubs

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

Example of tests using production version of stubs

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})

You can pass those values also via properties from your deployment pipeline.

86.5 Common repo with contracts

Another way of storing contracts other than having them with the producer is keeping them in a common place. + once you reach production deployment then you can run tests in one case with dev stubs and one with prod stubs.

Example of tests using development version of stubs

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

Example of tests using production version of stubs

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})

You can pass those values also via properties from your deployment pipeline.

82.5 Common repo with contracts

Another way of storing contracts other than having them with the producer is keeping them in a common place. It can be related to security issues where the consumers can’t clone the producer’s code. Also if you keep contracts in a single place then you, as a producer, will know how many consumers you have and which -consumer will you break with your local changes.

86.5.1 Repo structure

Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, +consumer will you break with your local changes.

82.5.1 Repo structure

Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup (which you can checkout here:

├── com
 │   └── example
@@ -271,11 +271,11 @@ Those poms are necessary for the consumer side to run mvn
 			</excludes>
 		</fileSet>
 	</fileSets>
-</assembly>

86.5.2 Workflow

The workflow would look similar to the one presented in the Step by step guide to CDC. The only difference +</assembly>

82.5.2 Workflow

The workflow would look similar to the one presented in the Step by step guide to CDC. The only difference is that the producer doesn’t own the contracts anymore. So the consumer and the producer have to work on - common contracts in a common repository.

86.5.3 Consumer

When the consumer wants to work on the contracts offline, instead of cloning the producer code, the + common contracts in a common repository.

82.5.3 Consumer

When the consumer wants to work on the contracts offline, instead of cloning the producer code, the consumer team clones the common repository, goes to the required producer’s folder (e.g. com/example/server) -and runs mvn clean install -DskipTests to install locally the stubs converted from the contracts.

[Tip]Tip

You need to have Maven installed locally

86.5.4 Producer

As a producer it’s enough to alter the Spring Cloud Contract Verifier to provide the URL and the dependency +and runs mvn clean install -DskipTests to install locally the stubs converted from the contracts.

[Tip]Tip

You need to have Maven installed locally

82.5.4 Producer

As a producer it’s enough to alter the Spring Cloud Contract Verifier to provide the URL and the dependency of the JAR containing the contracts:

<plugin>
 	<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -290,13 +290,13 @@ of the JAR containing the contracts:
http://link/to/your/nexus/or/artifactory/or/sth. It will be then unpacked in a local temporary folder
 and contracts present under the com/example/server will be picked as the ones used to generate the
 tests and the stubs. Due to this convention the producer team will know which consumer teams will be broken
-when some incompatible changes are done.
The rest of the flow looks the same.

86.6 Can I have multiple base classes for tests?

Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins.

86.7 How can I debug the request/response being sent by the generated tests client?

The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

logging.level.org.apache.http.wire=DEBUG

86.7.1 How can I debug the mapping/request/response being sent by WireMock?

Starting from version 1.2.0 we turn on WireMock logging to +when some incompatible changes are done.

The rest of the flow looks the same.

82.6 Can I have multiple base classes for tests?

Yes! Check out the Different base classes for contracts sections +of either Gradle or Maven plugins.

82.7 How can I debug the request/response being sent by the generated tests client?

The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

logging.level.org.apache.http.wire=DEBUG

82.7.1 How can I debug the mapping/request/response being sent by WireMock?

Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which -matching response definition was picked.

To turn off this feature just bump WireMock logging to ERROR

logging.level.com.github.tomakehurst.wiremock=ERROR

86.7.2 How can I see what got registered in the HTTP server stub?

You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule +matching response definition was picked.

To turn off this feature just bump WireMock logging to ERROR

logging.level.com.github.tomakehurst.wiremock=ERROR

82.7.2 How can I see what got registered in the HTTP server stub?

You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

86.7.3 Can I reference the request from the response?

Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support -for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

86.7.4 Can I reference text from file?

Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

82.7.3 Can I reference the request from the response?

Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support +for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

82.7.4 Can I reference text from file?

Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. -If you’re using YAML just use the bodyFromFile property.

Prev Up Next
85. Spring Cloud Contract Verifier Introduction Home 87. Spring Cloud Contract Verifier Setup
\ No newline at end of file +If you’re using YAML just use the bodyFromFile property.

Prev Up Next
81. Spring Cloud Contract Verifier Introduction Home 83. Spring Cloud Contract Verifier Setup
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_stub_runner.html b/Edgware.SR3/multi/multi__spring_cloud_contract_stub_runner.html index 417ecad9..f0a6bc40 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_stub_runner.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_stub_runner.html @@ -1,10 +1,10 @@ - 89. Spring Cloud Contract Stub Runner
89. Spring Cloud Contract Stub Runner
Prev Part XIII. Spring Cloud Contract Next

89. Spring Cloud Contract Stub Runner

One of the issues that you might encounter while using Spring Cloud Contract Verifier is + 85. Spring Cloud Contract Stub Runner

85. Spring Cloud Contract Stub Runner
Prev Part XII. Spring Cloud Contract Next

85. Spring Cloud Contract Stub Runner

One of the issues that you might encounter while using Spring Cloud Contract Verifier is passing the generated WireMock JSON stubs from the server side to the client side (or to various clients). The same takes place in terms of client-side generation for messaging.

Copying the JSON files and setting the client side for messaging manually is out of the question. That is why we introduced Spring Cloud Contract Stub Runner. It can -automatically download and run the stubs for you.

89.1 Snapshot versions

Add the additional snapshot repository to your build.gradle file to use snapshot +automatically download and run the stubs for you.

85.1 Snapshot versions

Add the additional snapshot repository to your build.gradle file to use snapshot versions, which are automatically uploaded after every successful build:

Maven.  

<repositories>
 	<repository>
@@ -67,7 +67,7 @@ versions, which are automatically uploaded after every successful build:
"http://repo.spring.io/milestone" }
 		maven { url "http://repo.spring.io/release" }
 	}

-

89.2 Publishing Stubs as JARs

The easiest approach would be to centralize the way stubs are kept. For example, you can +

85.2 Publishing Stubs as JARs

The easiest approach would be to centralize the way stubs are kept. For example, you can keep them as jars in a Maven repository.

[Tip]Tip

For both Maven and Gradle, the setup comes ready to work. However, you can customize it if you want to.

Maven.  

<!-- First disable the default jar setup in the properties section -->
@@ -155,9 +155,9 @@ publishing {
 		}
 	}
 }

-

89.3 Stub Runner Core

Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of +

85.3 Stub Runner Core

Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of Consumer Driven Contracts.

Stub Runner allows you to automatically download the stubs of the provided dependencies (or pick those from the classpath), start WireMock servers for them and feed them with proper stub definitions. -For messaging, special stub routes are defined.

89.3.1 Retrieving stubs

You can pick the following options of acquiring stubs

  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

The latter example is described in the Custom Stub Runner section.

Stub downloading

If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set +For messaging, special stub routes are defined.

85.3.1 Retrieving stubs

You can pick the following options of acquiring stubs

  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

The latter example is described in the Custom Stub Runner section.

Stub downloading

If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set to true then Stub Runner will connect to the given server and download the required jars. It will then unpack the JAR to a temporary folder and reference those files in further contract processing.

Example:

@AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095")

Classpath scanning

If you DON’T provide the stubrunner.repositoryRoot and stubrunner.workOffline flag will @@ -218,7 +218,7 @@ structure in your stubs jar.

└──
                 │       └── contract2.groovy
                 └── mappings
                     └── mapping.json

By maintaining this structure classpath gets scanned and you can profit from the messaging / -HTTP stubs without the need to download artifacts.

89.3.2 Running stubs

Limitations

[Important]Important

There might be a problem with StubRunner shutting down ports between tests. You might +HTTP stubs without the need to download artifacts.

85.3.2 Running stubs

Limitations

[Important]Important

There might be a problem with StubRunner shutting down ports between tests. You might have a situation in which you get port conflicts. As long as you use the same context across tests everything works fine. But when the context are different (e.g. different stubs or different profiles) then you have to either use @DirtiesContext to shut down the stub servers, or else run them on @@ -285,7 +285,7 @@ mappings available for the given server:

["uuid" : "f9152eb9-bf77-4c38-8289-90be7d10d0d7"
 },
 ...
-]

Messaging Stubs

Depending on the provided Stub Runner dependency and the DSL the messaging routes are automatically set up.

89.4 Stub Runner JUnit Rule

Stub Runner comes with a JUnit rule thanks to which you can very easily download and run stubs for given group and artifact id:

@ClassRule public static StubRunnerRule rule = new StubRunnerRule()
+]

Messaging Stubs

Depending on the provided Stub Runner dependency and the DSL the messaging routes are automatically set up.

85.4 Stub Runner JUnit Rule

Stub Runner comes with a JUnit rule thanks to which you can very easily download and run stubs for given group and artifact id:

@ClassRule public static StubRunnerRule rule = new StubRunnerRule()
 		.repoRoot(repoRoot())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer");

After that rule gets executed Stub Runner connects to your Maven repository and for the given list of dependencies tries to:

  • download them
  • cache them locally
  • unzip them to a temporary folder
  • start a WireMock server for each Maven dependency on a random port from the provided range of ports / provided port
  • feed the WireMock server with all JSON files that are valid WireMock definitions
  • can also send messages (remember to pass an implementation of MessageVerifier interface)

Stub Runner uses Eclipse Aether mechanism to download the Maven dependencies. @@ -368,14 +368,14 @@ def 'should outp then(httpGet(rule.findStubUrl("fraudDetectionServer").toString() + "/name")).isEqualTo("fraudDetectionServer"); }

Check the Common properties for JUnit and Spring for more information on how to apply global configuration of Stub Runner.

[Important]Important

To use the JUnit rule together with messaging you have to provide an implementation of the MessageVerifier interface to the rule builder (e.g. rule.messageVerifier(new MyMessageVerifier())). -If you don’t do this then whenever you try to send a message an exception will be thrown.

89.4.1 Maven settings

The stub downloader honors Maven settings for a different local repository folder. -Authentication details for repositories and profiles are currently not taken into account, so you need to specify it using the properties mentioned above.

89.4.2 Providing fixed ports

You can also run your stubs on fixed ports. You can do it in two different ways. One is to pass it in the properties, and the other via fluent API of -JUnit rule.

89.4.3 Fluent API

When using the StubRunnerRule you can add a stub to download and then pass the port for the last downloaded stub.

@ClassRule public static StubRunnerRule rule = new StubRunnerRule()
+If you don’t do this then whenever you try to send a message an exception will be thrown.

85.4.1 Maven settings

The stub downloader honors Maven settings for a different local repository folder. +Authentication details for repositories and profiles are currently not taken into account, so you need to specify it using the properties mentioned above.

85.4.2 Providing fixed ports

You can also run your stubs on fixed ports. You can do it in two different ways. One is to pass it in the properties, and the other via fluent API of +JUnit rule.

85.4.3 Fluent API

When using the StubRunnerRule you can add a stub to download and then pass the port for the last downloaded stub.

@ClassRule public static StubRunnerRule rule = new StubRunnerRule()
 		.repoRoot(repoRoot())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.withPort(12345)
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer:12346");

You can see that for this example the following test is valid:

then(rule.findStubUrl("loanIssuance")).isEqualTo(URI.create("http://localhost:12345").toURL());
-then(rule.findStubUrl("fraudDetectionServer")).isEqualTo(URI.create("http://localhost:12346").toURL());

89.4.4 Stub Runner with Spring

Sets up Spring configuration of the Stub Runner project.

By providing a list of stubs inside your configuration file the Stub Runner automatically downloads +then(rule.findStubUrl("fraudDetectionServer")).isEqualTo(URI.create("http://localhost:12346").toURL());

85.4.4 Stub Runner with Spring

Sets up Spring configuration of the Stub Runner project.

By providing a list of stubs inside your configuration file the Stub Runner automatically downloads and registers in WireMock the selected stubs.

If you want to find the URL of your stubbed dependency you can autowire the StubFinder interface and use its methods as presented below:

@ContextConfiguration(classes = Config, loader = SpringBootContextLoader)
 @SpringBootTest(properties = [" stubrunner.cloud.enabled=false",
@@ -465,7 +465,7 @@ Below you can find an example of achieving the same result by setting values on
 		"org.springframework.cloud.contract.verifier.stubs:bootService"],
 		repositoryRoot = "classpath:m2repo/repository/")

Stub Runner Spring registers environment variables in the following manner for every registered WireMock server. Example for Stub Runner ids - com.example:foo, com.example:bar.

  • stubrunner.runningstubs.foo.port
  • stubrunner.runningstubs.bar.port

Which you can reference in your code.

89.5 Stub Runner Spring Cloud

Stub Runner can integrate with Spring Cloud.

For real life examples you can check the

89.5.1 Stubbing Service Discovery

The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

  • DiscoveryClient
  • Ribbon ServerList

that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. + com.example:foo, com.example:bar.

  • stubrunner.runningstubs.foo.port
  • stubrunner.runningstubs.bar.port

Which you can reference in your code.

85.5 Stub Runner Spring Cloud

Stub Runner can integrate with Spring Cloud.

For real life examples you can check the

85.5.1 Stubbing Service Discovery

The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

  • DiscoveryClient
  • Ribbon ServerList

that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using Feign, load balanced RestTemplate or DiscoveryClient directly, to call those stubbed servers instead of calling the real Service Discovery tool.

For example this test will pass

def 'should make service discovery work'() {
 	expect: 'WireMocks are running'
@@ -484,16 +484,16 @@ via a static block like presented below (example for Eureka)
static {
         System.setProperty("eureka.client.enabled", "false");
         System.setProperty("spring.cloud.config.failFast", "false");
-    }

89.5.2 Additional Configuration

You can match the artifactId of the stub with the name of your app by using the stubrunner.idsToServiceIds: map. + }

85.5.2 Additional Configuration

You can match the artifactId of the stub with the name of your app by using the stubrunner.idsToServiceIds: map. You can disable Stub Runner Ribbon support by providing: stubrunner.cloud.ribbon.enabled equal to false You can disable Stub Runner support by providing: stubrunner.cloud.enabled equal to false

[Tip]Tip

By default all service discovery will be stubbed. That means that regardless of the fact if you have an existing DiscoveryClient its results will be ignored. However, if you want to reuse it, just set stubrunner.cloud.delegate.enabled to true and then your existing DiscoveryClient results will be merged with the stubbed ones.

The default Maven configuration used by Stub Runner can be tweaked either -via the following system properties or environment variables

  • maven.repo.local - path to the custom maven local repository location
  • org.apache.maven.user-settings - path to custom maven user settings location
  • org.apache.maven.global-settings - path to maven global settings location

89.6 Stub Runner Boot Application

Spring Cloud Contract Stub Runner Boot is a Spring Boot application that exposes REST endpoints to +via the following system properties or environment variables

  • maven.repo.local - path to the custom maven local repository location
  • org.apache.maven.user-settings - path to custom maven user settings location
  • org.apache.maven.global-settings - path to maven global settings location

85.6 Stub Runner Boot Application

Spring Cloud Contract Stub Runner Boot is a Spring Boot application that exposes REST endpoints to trigger the messaging labels and to access started WireMock servers.

One of the use-cases is to run some smoke (end to end) tests on a deployed application. You can check out the Spring Cloud Pipelines -project for more information.

89.6.1 How to use it?

Stub Runner Server

Just add the

compile "org.springframework.cloud:spring-cloud-starter-stub-runner"

Annotate a class with @EnableStubRunnerServer, build a fat-jar and you’re ready to go!

For the properties check the Stub Runner Spring section.

Stub Runner Server Fat Jar

You can download a standalone JAR from Maven (for example, for version 1.2.3.RELEASE), as follows:

$ wget -O stub-runner.jar 'https://search.maven.org/remote_content?g=org.springframework.cloud&a=spring-cloud-contract-stub-runner-boot&v=1.2.3.RELEASE'
+project for more information.
85.6.1 How to use it?
Stub Runner Server
Just add the
compile "org.springframework.cloud:spring-cloud-starter-stub-runner"
Annotate a class with @EnableStubRunnerServer, build a fat-jar and you’re ready to go!
For the properties check the Stub Runner Spring section.
Stub Runner Server Fat Jar
You can download a standalone JAR from Maven (for example, for version 1.2.3.RELEASE), as follows:
$ wget -O stub-runner.jar 'https://search.maven.org/remote_content?g=org.springframework.cloud&a=spring-cloud-contract-stub-runner-boot&v=1.2.3.RELEASE'
 $ java -jar stub-runner.jar --stubrunner.ids=... --stubrunner.repositoryRoot=...
Spring Cloud CLI
Starting from 1.4.0.RELEASE version of the Spring Cloud CLI
 project you can start Stub Runner Boot by executing spring cloud stubrunner.
In order to pass the configuration just create a stubrunner.yml file in the current working directory
 or a subdirectory called config or in ~/.spring-cloud. The file could look like this
@@ -503,7 +503,7 @@ or a subdirectory called config or in spring cloud stubrunner from your terminal window to start
-the Stub Runner server. It will be available at port 8750.
89.6.2 Endpoints
HTTP
  • GET /stubs - returns a list of all running stubs in ivy:integer notation
  • GET /stubs/{ivy} - returns a port for the given ivy notation (when calling the endpoint ivy can also be artifactId only)
Messaging
For Messaging
  • GET /triggers - returns a list of all running labels in ivy : [ label1, label2 …​] notation
  • POST /triggers/{label} - executes a trigger with label
  • POST /triggers/{ivy}/{label} - executes a trigger with label for the given ivy notation (when calling the endpoint ivy can also be artifactId only)
89.6.3 Example
@ContextConfiguration(classes = StubRunnerBoot, loader = SpringBootContextLoader)
+the Stub Runner server. It will be available at port 8750.

85.6.2 Endpoints

HTTP

  • GET /stubs - returns a list of all running stubs in ivy:integer notation
  • GET /stubs/{ivy} - returns a port for the given ivy notation (when calling the endpoint ivy can also be artifactId only)

Messaging

For Messaging

  • GET /triggers - returns a list of all running labels in ivy : [ label1, label2 …​] notation
  • POST /triggers/{label} - executes a trigger with label
  • POST /triggers/{ivy}/{label} - executes a trigger with label for the given ivy notation (when calling the endpoint ivy can also be artifactId only)

85.6.3 Example

@ContextConfiguration(classes = StubRunnerBoot, loader = SpringBootContextLoader)
 @SpringBootTest(properties = "spring.cloud.zookeeper.enabled=false")
 @ActiveProfiles("test")
 class StubRunnerBootSpec extends Specification {
@@ -589,7 +589,7 @@ the Stub Runner server. It will be available at port 8750<
 			e.message.contains("org.springframework.cloud.contract.verifier.stubs:bootService:0.0.1-SNAPSHOT:stubs=")
 	}
 
-}

89.6.4 Stub Runner Boot with Service Discovery

One of the possibilities of using Stub Runner Boot is to use it as a feed of stubs for "smoke-tests". What does it mean? +}

85.6.4 Stub Runner Boot with Service Discovery

One of the possibilities of using Stub Runner Boot is to use it as a feed of stubs for "smoke-tests". What does it mean? Let’s assume that you don’t want to deploy 50 microservice to a test environment in order to check if your application is working fine. You’ve already executed a suite of tests during the build process but you would also like to ensure that the packaging of your application is fine. What you can do @@ -622,7 +622,7 @@ and we want to have the stub runner feature turned on @Aut (4) - we provide a list of artifactId to serviceId mapping

That way your deployed application can send requests to started WireMock servers via the service discovery. Most likely points 1-3 could be set by default in application.yml cause they are not likely to change. That way you can provide only the list of stubs to download whenever you start -the Stub Runner Boot.

89.7 Stubs Per Consumer

There are cases in which 2 consumers of the same endpoint want to have 2 different responses.

[Tip]Tip

This approach also allows you to immediately know which consumer is using which part of your API. +the Stub Runner Boot.

85.7 Stubs Per Consumer

There are cases in which 2 consumers of the same endpoint want to have 2 different responses.

[Tip]Tip

This approach also allows you to immediately know which consumer is using which part of your API. You can remove part of a response that your API produces and you can see which of your autogenerated tests fails. If none fails then you can safely delete that part of the response cause nobody is using it.

Let’s look at the following example for contract defined for the producer called producer. There are 2 consumers: foo-consumer and bar-consumer.

Consumer foo-service

request {
@@ -675,26 +675,26 @@ Or set the test as follows:
foo-consumer in its name (i.e. those from the
 src/test/resources/contracts/foo-consumer/some/contracts/…​ folder) will be allowed to be referenced.
You can check out issue 224 for more
-information about the reasons behind this change.

89.8 Common

This section briefly describes common properties, including:

89.8.1 Common Properties for JUnit and Spring

You can set repetitive properties by using system properties or Spring configuration +information about the reasons behind this change.

85.8 Common

This section briefly describes common properties, including:

85.8.1 Common Properties for JUnit and Spring

You can set repetitive properties by using system properties or Spring configuration properties. Here are their names with their default values:

Property nameDefault valueDescription

stubrunner.minPort

10000

Minimum value of a port for a started WireMock with stubs.

stubrunner.maxPort

15000

Maximum value of a port for a started WireMock with stubs.

stubrunner.repositoryRoot

 

Maven repo URL. If blank, then call the local maven repo.

stubrunner.classifier

stubs

Default classifier for the stub artifacts.

stubrunner.workOffline

false

If true, then do not contact any remote repositories to download stubs.

stubrunner.ids

 

Array of Ivy notation stubs to download.

stubrunner.username

 

Optional username to access the tool that stores the JARs with stubs.

stubrunner.password

 

Optional password to access the tool that stores the JARs with stubs.

stubrunner.stubsPerConsumer

false

Set to true if you want to use different stubs for each consumer instead of registering all stubs for every consumer.

stubrunner.consumerName

 

If you want to use a stub for each consumer and want to -override the consumer name just change this value.

89.8.2 Stub Runner Stubs IDs

You can provide the stubs to download via the stubrunner.ids system property. They +override the consumer name just change this value.

85.8.2 Stub Runner Stubs IDs

You can provide the stubs to download via the stubrunner.ids system property. They follow this pattern:

groupId:artifactId:version:classifier:port

Note that version, classifier and port are optional.

  • If you do not provide the port, a random one will be picked.
  • If you do not provide the classifier, the default is used. (Note that you can pass an empty classifier this way: groupId:artifactId:version:).
  • If you do not provide the version, then the + will be passed and the latest one is downloaded.

port means the port of the WireMock server.

[Important]Important

Starting with version 1.0.4, you can provide a range of versions that you would like the Stub Runner to take into consideration. You can read more about the Aether versioning -ranges here.

89.9 Stub Runner Docker

We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image +ranges here.

85.9 Stub Runner Docker

We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image that will start the standalone version of Stub Runner.

If you want to learn more about the basics of Maven, artifact ids, -group ids, classifiers and Artifact Managers, just click here Section 87.6, “Docker Project”.

89.9.1 How to use it

Just execute the docker image. You can pass any of the Section 89.8.1, “Common Properties for JUnit and Spring” +group ids, classifiers and Artifact Managers, just click here Section 83.6, “Docker Project”.

85.9.1 How to use it

Just execute the docker image. You can pass any of the Section 85.8.1, “Common Properties for JUnit and Spring” as environment variables. The convention is that all the letters should be upper case. The camel case notation should and the dot (.) should be separated via underscore (_). E.g. the stubrunner.repositoryRoot property should be represented - as a STUBRUNNER_REPOSITORY_ROOT environment variable.

89.9.2 Example of client side usage in a non JVM project

We’d like to use the stubs created in this Section 87.6.4, “Server side (nodejs)” step. + as a STUBRUNNER_REPOSITORY_ROOT environment variable.

85.9.2 Example of client side usage in a non JVM project

We’d like to use the stubs created in this Section 83.6.4, “Server side (nodejs)” step. Let’s assume that we want to run the stubs on port 9876. The NodeJS code is available here:

$ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
 $ cd bookstore

Let’s run the Stub Runner Boot application with the stubs.

# Provide the Spring Cloud Contract Docker version
@@ -712,4 +712,4 @@ that the stubs are setup properly.
"Content-Type:application/json" -X POST --data '{ "title" : "Title", "genre" : "Genre", "description" : "Description", "author" : "Author", "publisher" : "Publisher", "pages" : 100, "image_url" : "https://d213dhlpdb53mu.cloudfront.net/assets/pivotal-square-logo-41418bd391196c3022f3cd9f3959b3f6d7764c47873d858583384e759c7db435.svg", "buy_url" : "https://pivotal.io" }' http://localhost:9876/api/books
 # Now time for the second request
 $ curl -X GET http://localhost:9876/api/books
-# You will receive contents of the JSON
Prev Up Next
88. Spring Cloud Contract Verifier Messaging Home 90. Stub Runner for Messaging
\ No newline at end of file +# You will receive contents of the JSON
Prev Up Next
84. Spring Cloud Contract Verifier Messaging Home 86. Stub Runner for Messaging
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_introduction.html b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_introduction.html index cd07804e..1469be6f 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -1,6 +1,6 @@ - 85. Spring Cloud Contract Verifier Introduction
85. Spring Cloud Contract Verifier Introduction
Prev Part XIII. Spring Cloud Contract Next

85. Spring Cloud Contract Verifier Introduction

[Tip]Tip

The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski + 81. Spring Cloud Contract Verifier Introduction

81. Spring Cloud Contract Verifier Introduction
Prev Part XII. Spring Cloud Contract Next

81. Spring Cloud Contract Verifier Introduction

[Tip]Tip

The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski (codearte.io)

Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture.

Spring Cloud Contract Verifier ships with Contract Definition Language (CDL). Contract definitions are used to produce the following resources:

  • JSON stub definitions to be used by WireMock when doing integration testing on the @@ -9,7 +9,7 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.

85.1 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

85.1.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

81.1 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

81.1.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

  • Deploy all microservices and perform end-to-end tests.
  • Mock other microservices in unit/integration tests.

Both have their advantages but also a lot of disadvantages.

Deploy all microservices and perform end to end tests

Advantages:

  • Simulates production.
  • Tests real communication between services.

Disadvantages:

  • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
  • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
  • They take a long time to run.
  • The feedback comes very late in the process.
  • They are extremely hard to debug.

Mock other microservices in unit/integration tests

Advantages:

  • They provide very fast feedback.
  • They have no infrastructure requirements.

Disadvantages:

  • The implementor of the service creates stubs that might have nothing to do with @@ -18,13 +18,13 @@ created. The main idea is to give you very fast feedback, without the need to se whole world of microservices. If you work on stubs, then the only applications you need are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they -were tested against the producer’s side. In short, you can trust those stubs.

85.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly +were tested against the producer’s side. In short, you can trust those stubs.

81.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
  • To promote ATDD method and Microservices architectural style.
  • To provide a way to publish changes in contracts that are immediately visible on both sides.
  • To generate boilerplate test code to be used on the server side.
[Important]Important

Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts, one for the positive case and one for the negative case. Contract tests are -used to test contracts between applications and not to simulate full behavior.

85.3 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

85.3.1 Defining the contract

As consumers of services, we need to define what exactly we want to achieve. We need to +used to test contracts between applications and not to simulate full behavior.

81.3 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

81.3.1 Defining the contract

As consumers of services, we need to define what exactly we want to achieve. We need to formulate our expectations. That is why we write contracts.

Assume that you want to send a request containing the ID of a client company and the amount it wants to borrow from us. You also want to send it to the /fraudcheck url via the PUT method.

Groovy DSL.  @@ -138,7 +138,7 @@ response: # (7) #(9) - and JSON body equal to # { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" } #(10) - with header `Content-Type` equal to `application/json;charset=UTF-8`

-

85.3.2 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. +

81.3.2 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. You get a running WireMock instance/Messaging route that simulates the service. You would like to feed that instance with a proper stub definition.

At some point in time, you need to send a request to the Fraud Detection service.

ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
@@ -149,7 +149,7 @@ You would like to feed that instance with a proper stub definition.
At som
 @DirtiesContext
 public class LoanApplicationServiceTests {

After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured -(or random) port.

85.3.3 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your +(or random) port.

81.3.3 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your concrete implementation. You cannot have a situation where your stub acts in one way and your application behaves in a different way, especially in production.

To ensure that your application behaves the way you define in your stub, tests are generated from the stub you provide.

The autogenerated test looks, more or less, like this:

@Test
@@ -170,7 +170,7 @@ generated from the stub you provide.
The autogenerated test looks, more or
         DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());
         assertThatJson(parsedJson).field("['fraudCheckStatus']").matches("[A-Z]{5}");
         assertThatJson(parsedJson).field("['rejection.reason']").isEqualTo("Amount too high");
-}

85.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business +}

81.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business scenario is such that we want to issue loans to people but do not want them to steal from us. The current implementation of our system grants loans to everybody.

Assume that Loan Issuance is a client to the Fraud Detection server. In the current sprint, we must develop a new feature: if a client wants to borrow too much money, then @@ -179,7 +179,7 @@ Issuance has an artifact-id of http-client, and bot discuss changes while going through the process. CDC is all about communication.

The server side code is available here and the client code here.

[Tip]Tip

In this case, the producer owns the contracts. Physically, all the contract are -in the producer’s repository.

85.4.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the +in the producer’s repository.

81.4.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

Maven.  

<repositories>
 	<repository>
@@ -241,7 +241,7 @@ following section to your build:
Maven. 
 	maven { url "http://repo.spring.io/milestone" }
 	maven { url "http://repo.spring.io/release" }
 }

-

85.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
+

81.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
 	// given:
 	LoanApplication application = new LoanApplication(new Client("1234567890"),
@@ -455,7 +455,7 @@ with group id com.example, artifact id stubs classifier on port 8080.
File a pull request.
What you have done until now is an iterative process. You can play around with the
 contract, install it locally, and work on the consumer side until the contract works as
 you wish.
Once you are satisfied with the results and the test passes, publish a pull request to
-the server side. Currently, the consumer side work is done.

85.4.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
+the server side. Currently, the consumer side work is done.

81.4.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
 public FraudCheckResult fraudCheck(@RequestBody FraudCheck fraudCheck) {
 return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
 }

Take over the pull request.

$ git checkout -b contract-change-pr master
@@ -547,15 +547,15 @@ Contract Verifier plugin adds the tests to the gene
 actually run those tests from your IDE.
Deploy your app.
Once you finish your work, you can deploy your change. First, merge the branch:
$ git checkout master
 $ git merge --no-ff contract-change-pr
 $ git push origin master
Your CI might run something like ./mvnw clean deploy, which would publish both the
-application and the stub artifacts.

85.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
+application and the stub artifacts.

81.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
 $ git merge --no-ff contract-change-pr

Work online.

Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can switch off the value of the workOffline parameter in your annotation. The following code shows an example of achieving the same thing by changing the properties.

stubrunner:
   ids: 'com.example:http-server-dsl:+:stubs:8080'
-  repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

85.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add -spring-cloud-starter-contract-verifier.

85.6 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note + repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

81.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add +spring-cloud-starter-contract-verifier.

81.6 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under -constant development.

85.6.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

85.6.2 Readings

85.7 Samples

You can find some samples at -samples.

Prev Up Next
84. Spring Cloud Contract Home 86. Spring Cloud Contract FAQ
\ No newline at end of file +constant development.

81.6.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

81.6.2 Readings

81.7 Samples

You can find some samples at +samples.

Prev Up Next
80. Spring Cloud Contract Home 82. Spring Cloud Contract FAQ
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_messaging.html b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_messaging.html index 24beed2a..31fac9ac 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_messaging.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_messaging.html @@ -1,8 +1,8 @@ - 88. Spring Cloud Contract Verifier Messaging
88. Spring Cloud Contract Verifier Messaging
Prev Part XIII. Spring Cloud Contract Next

88. Spring Cloud Contract Verifier Messaging

Spring Cloud Contract Verifier lets you verify applications that uses messaging as a + 84. Spring Cloud Contract Verifier Messaging

84. Spring Cloud Contract Verifier Messaging
Prev Part XII. Spring Cloud Contract Next

84. Spring Cloud Contract Verifier Messaging

Spring Cloud Contract Verifier lets you verify applications that uses messaging as a means of communication. All of the integrations shown in this document work with Spring, -but you can also create one of your own and use that.

88.1 Integrations

You can use one of the following four integration configurations:

  • Apache Camel
  • Spring Integration
  • Spring Cloud Stream
  • Spring AMQP

Since we use Spring Boot, if you have added one of these libraries to the classpath, all +but you can also create one of your own and use that.

84.1 Integrations

You can use one of the following four integration configurations:

  • Apache Camel
  • Spring Integration
  • Spring Cloud Stream
  • Spring AMQP

Since we use Spring Boot, if you have added one of these libraries to the classpath, all the messaging configuration is automatically set up.

[Important]Important

Remember to put @AutoConfigureMessageVerifier on the base class of your generated tests. Otherwise, messaging part of Spring Cloud Contract Verifier does not work.

[Important]Important

If you want to use Spring Cloud Stream, remember to add a dependency on @@ -14,7 +14,7 @@ work.

</dependency>

Gradle.  

testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

-

88.2 Manual Integration Testing

The main interface used by the tests is +

84.2 Manual Integration Testing

The main interface used by the tests is org.springframework.cloud.contract.verifier.messaging.MessageVerifier. It defines how to send and receive messages. You can create your own implementation to achieve the same goal.

In a test, you can inject a ContractVerifierMessageExchange to send and receive @@ -28,14 +28,14 @@ Here’s an example:

private MessageVerifier verifier;
   ...
 }
[Note]Note

If your tests require stubs as well, then @AutoConfigureStubRunner includes the -messaging configuration, so you only need the one annotation.

88.3 Publisher-Side Test Generation

Having the input or outputMessage sections in your DSL results in creation of tests +messaging configuration, so you only need the one annotation.

84.3 Publisher-Side Test Generation

Having the input or outputMessage sections in your DSL results in creation of tests on the publisher’s side. By default, JUnit tests are created. However, there is also a possibility to create Spock tests.

There are 3 main scenarios that we should take into consideration:

  • Scenario 1: There is no input message that produces an output message. The output message is triggered by a component inside the application (for example, scheduler).
  • Scenario 2: The input message triggers an output message.
  • Scenario 3: The input message is consumed and there is no output message.
[Important]Important

The destination passed to messageFrom or sentTo can have different meanings for different messaging implementations. For Stream and Integration it is first resolved as a destination of a channel. Then, if there is no such destination it is resolved as a channel name. For Camel, that’s a certain component (for example, -jms).

88.3.1 Scenario 1: No Input Message

Here is an example for Camel. For the given contract:

Groovy DSL.  +jms).

84.3.1 Scenario 1: No Input Message

Here is an example for Camel. For the given contract:

Groovy DSL.  

def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -88,7 +88,7 @@ outputMessage:
   DocumentContext parsedJson = JsonPath.parse(contractVerifierObjectMapper.writeValueAsString(response.payload))
   assertThatJson(parsedJson).field("bookName").isEqualTo("foo")
 
-'''

88.3.2 Scenario 2: Output Triggered by Input

Here is an example for Camel. For the given contract:

Groovy DSL.  +'''

84.3.2 Scenario 2: Output Triggered by Input

Here is an example for Camel. For the given contract:

Groovy DSL.  

def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -159,7 +159,7 @@ then:
 and:
    DocumentContext parsedJson = JsonPath.parse(contractVerifierObjectMapper.writeValueAsString(response.payload))
    assertThatJson(parsedJson).field("bookName").isEqualTo("foo")
-"""

88.3.3 Scenario 3: No Output Message

Here is an example for Camel. For the given contract:

Groovy DSL.  +"""

84.3.3 Scenario 3: No Output Message

Here is an example for Camel. For the given contract:

Groovy DSL.  

def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -207,7 +207,7 @@ when:
 then:
 	 noExceptionThrown()
 	 bookWasDeleted()
-'''

88.4 Consumer Stub Generation

Unlike the HTTP part, in messaging, we need to publish the Groovy DSL inside the JAR with +'''

84.4 Consumer Stub Generation

Unlike the HTTP part, in messaging, we need to publish the Groovy DSL inside the JAR with a stub. Then it is parsed on the consumer side and proper stubbed routes are created.

For more information, see the Stub Runner Messaging sections.

Maven.  @@ -259,4 +259,4 @@ publishing { } } }

-

Prev Up Next
87. Spring Cloud Contract Verifier Setup Home 89. Spring Cloud Contract Stub Runner
\ No newline at end of file +

Prev Up Next
83. Spring Cloud Contract Verifier Setup Home 85. Spring Cloud Contract Stub Runner
\ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_setup.html b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_setup.html index e50c1b30..550f1b2c 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_verifier_setup.html @@ -1,10 +1,10 @@ - 87. Spring Cloud Contract Verifier Setup
87. Spring Cloud Contract Verifier Setup
Prev Part XIII. Spring Cloud Contract Next

87. Spring Cloud Contract Verifier Setup

You can set up Spring Cloud Contract Verifier in the following ways:

87.1 Gradle Project

To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the -following sections:

87.1.1 Prerequisites

In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a + 83. Spring Cloud Contract Verifier Setup

83. Spring Cloud Contract Verifier Setup
Prev Part XII. Spring Cloud Contract Next

83. Spring Cloud Contract Verifier Setup

You can set up Spring Cloud Contract Verifier in the following ways:

83.1 Gradle Project

To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the +following sections:

83.1.1 Prerequisites

In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a Gradle or a Maven plugin.

[Warning]Warning

If you want to use Spock in your projects, you must add separately the spock-core and spock-spring modules. Check Spock -docs for more information

87.1.2 Add Gradle Plugin with Dependencies

To add a Gradle plugin with dependencies, use code similar to this:

buildscript {
+docs for more information

83.1.2 Add Gradle Plugin with Dependencies

To add a Gradle plugin with dependencies, use code similar to this:

buildscript {
 	repositories {
 		mavenCentral()
 	}
@@ -29,7 +29,7 @@ dependencies {
 	testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
 	testCompile 'org.spockframework:spock-spring:1.0-groovy-2.4'
 	testCompile 'org.springframework.cloud:spring-cloud-starter-contract-verifier'
-}

87.1.3 Gradle and Rest Assured 2.0

By default, Rest Assured 3.x is added to the classpath. However, to use Rest Assured 2.x +}

83.1.3 Gradle and Rest Assured 2.0

By default, Rest Assured 3.x is added to the classpath. However, to use Rest Assured 2.x you can add it to the plugins classpath, as shown here:

buildscript {
 	repositories {
 		mavenCentral()
@@ -48,7 +48,7 @@ depenendencies {
     testCompile "com.jayway.restassured:rest-assured:2.5.0"
     testCompile "com.jayway.restassured:spring-mock-mvc:2.5.0"
 }

That way, the plugin automatically sees that Rest Assured 2.x is present on the classpath -and modifies the imports accordingly.

87.1.4 Snapshot Versions for Gradle

Add the additional snapshot repository to your build.gradle to use snapshot versions, +and modifies the imports accordingly.

83.1.4 Snapshot Versions for Gradle

Add the additional snapshot repository to your build.gradle to use snapshot versions, which are automatically uploaded after every successful build, as shown here:

buildscript {
 	repositories {
 		mavenCentral()
@@ -57,16 +57,16 @@ which are automatically uploaded after every successful build, as shown here:
"http://repo.spring.io/milestone" }
 		maven { url "http://repo.spring.io/release" }
 	}
-}

87.1.5 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the +}

83.1.5 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory.

The directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test. Spring Cloud Contract Verifier assumes that it contains at least one level of directories that are to be used as the test class name. If more than one level of nested directories is present, all except the last one is used as the package name. For example, with following structure:

src/test/resources/contracts/myservice/shouldCreateUser.groovy
 src/test/resources/contracts/myservice/shouldReturnUser.groovy

Spring Cloud Contract Verifier creates a test class named defaultBasePackage.MyService -with two methods:

  • shouldCreateUser()
  • shouldReturnUser()

87.1.6 Run the Plugin

The plugin registers itself to be invoked before a check task. If you want it to be +with two methods:

  • shouldCreateUser()
  • shouldReturnUser()

83.1.6 Run the Plugin

The plugin registers itself to be invoked before a check task. If you want it to be part of your build process, you need to do nothing more. If you just want to generate -tests, invoke the generateContractTests task.

87.1.7 Default Setup

The default Gradle Plugin setup creates the following Gradle part of the build (in +tests, invoke the generateContractTests task.

83.1.7 Default Setup

The default Gradle Plugin setup creates the following Gradle part of the build (in pseudocode):

contracts {
     targetFramework = 'JUNIT'
     testMode = 'MockMvc'
@@ -110,12 +110,12 @@ publishing {
             artifact verifierStubsJar
         }
     }
-}

87.1.8 Configure Plugin

To change the default configuration, add a contracts snippet to your Gradle config, as +}

83.1.8 Configure Plugin

To change the default configuration, add a contracts snippet to your Gradle config, as shown here:

contracts {
 	testMode = 'MockMvc'
 	baseClassForTests = 'org.mycompany.tests'
 	generatedTestSourcesDir = project.file('src/generatedContract')
-}

87.1.9 Configuration Options

  • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, +}

83.1.9 Configuration Options

  • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, which is based on Spring’s MockMvc. It can also be changed to JaxRsClient or to Explicit for real HTTP calls.
  • imports: Creates an array with imports that should be included in generated tests (for example ['org.myorg.Matchers']). By default, it creates an empty array.
  • staticImports: Creates an array with static imports that should be included in @@ -143,7 +143,7 @@ closure to set it up. separated. Otherwise, it scans contracts under the provided directory. * contractsWorkOffline: Specifies whether to download the dependencies each time, so that you can work online. In other words, it specifies whether to reuses the local Maven -repo.

87.1.10 Single Base Class for All Tests

When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base +repo.

83.1.10 Single Base Class for All Tests

When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base specification for all generated acceptance tests. In this class, you need to point to an endpoint, which should be verified.

abstract class BaseMockMvcSpec extends Specification {
 
@@ -162,7 +162,7 @@ endpoint, which should be verified.
If you use Explicit mode, you can use a base class to initialize the whole tested app
 as you might see in regular integration tests. If you use the JAXRSCLIENT mode, this
 base class should also contain a protected WebTarget webTarget field. Right now, the
-only option to test the JAX-RS API is to start a web server.

87.1.11 Different Base Classes for Contracts

If your base classes differ between contracts, you can tell the Spring Cloud Contract +only option to test the JAX-RS API is to start a web server.

83.1.11 Different Base Classes for Contracts

If your base classes differ between contracts, you can tell the Spring Cloud Contract plugin which class should get extended by the autogenerated tests. You have two options:

  • Follow a convention by providing the packageWithBaseClasses
  • Provide explicit mapping via baseClassMappings

By Convention

The convention is such that if you have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set the value of the packageWithBaseClasses property to com.example.base, then Spring Cloud Contract @@ -181,7 +181,7 @@ baseClassMappings { - src/test/resources/contract/foo/

By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You could also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

87.1.12 Invoking Generated Tests

To ensure that the provider side is compliant with defined contracts, you need to invoke:

./gradlew generateContractTests test

87.1.13 Spring Cloud Contract Verifier on the Consumer Side

In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

83.1.12 Invoking Generated Tests

To ensure that the provider side is compliant with defined contracts, you need to invoke:

./gradlew generateContractTests test

83.1.13 Spring Cloud Contract Verifier on the Consumer Side

In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you do not want to use Stub Runner then you need to copy contracts stored in src/test/resources/contracts and generate WireMock JSON stubs using:

./gradlew generateClientStubs
[Note]Note

The stubsOutputDir option has to be set for stub generation to work.

When present, JSON stubs can be used in automated tests of consuming a service.

@ContextConfiguration(loader == SpringApplicationContextLoader, classes == Application)
@@ -205,8 +205,8 @@ WireMock JSON stubs using:
./gradlew generateClie
 	loanApplication.rejectionReason == null
  }
 }
LoanApplication makes a call to FraudDetection service. This request is handled by a
-WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

87.2 Maven Project

To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the -following sections:

87.2.1 Add maven plugin

Add the Spring Cloud Contract BOM in a fashion similar to this:

<dependencyManagement>
+WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

83.2 Maven Project

To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the +following sections:

83.2.1 Add maven plugin

Add the Spring Cloud Contract BOM in a fashion similar to this:

<dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -226,7 +226,7 @@ following sections:
    </configuration>
 </plugin>

You can read more in the Spring -Cloud Contract Maven Plugin Documentation.

87.2.2 Maven and Rest Assured 2.0

By default, Rest Assured 3.x is added to the classpath. However, you can use Rest +Cloud Contract Maven Plugin Documentation.

83.2.2 Maven and Rest Assured 2.0

By default, Rest Assured 3.x is added to the classpath. However, you can use Rest Assured 2.x by adding it to the plugins classpath, as shown here:

<plugin>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -272,7 +272,7 @@ Assured 2.x by adding it to the plugins classpath, as shown here:
That way, the plugin automatically sees that Rest Assured 3.x is present on the classpath
-and modifies the imports accordingly.

87.2.3 Snapshot versions for Maven

For Snapshot and Milestone versions, you have to add the following section to your +and modifies the imports accordingly.

83.2.3 Snapshot versions for Maven

For Snapshot and Milestone versions, you have to add the following section to your pom.xml, as shown here:

<repositories>
 	<repository>
 		<id>spring-snapshots</id>
@@ -324,16 +324,16 @@ and modifies the imports accordingly.
<enabled>false</enabled> </snapshots> </pluginRepository> -</pluginRepositories>

87.2.4 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the +</pluginRepositories>

83.2.4 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory. The directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test. We assume that it contains at least one directory to be used as test class name. If there is more than one level of nested directories, all except the last one is used as package name. For example, with following structure:

src/test/resources/contracts/myservice/shouldCreateUser.groovy
 src/test/resources/contracts/myservice/shouldReturnUser.groovy

Spring Cloud Contract Verifier creates a test class named defaultBasePackage.MyService -with two methods

  • shouldCreateUser()
  • shouldReturnUser()

87.2.5 Run plugin

The plugin goal generateTests is assigned to be invoked in the phase called +with two methods

  • shouldCreateUser()
  • shouldReturnUser()

83.2.5 Run plugin

The plugin goal generateTests is assigned to be invoked in the phase called generate-test-sources. If you want it to be part of your build process, you need not do -anything. If you just want to generate tests, invoke the generateTests goal.

87.2.6 Configure plugin

To change the default configuration, just add a configuration section to the plugin +anything. If you just want to generate tests, invoke the generateTests goal.

83.2.6 Configure plugin

To change the default configuration, just add a configuration section to the plugin definition or the execution definition, as shown here:

<plugin>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -350,7 +350,7 @@ definition or the execution definition, as shown he
         <basePackageForTests>org.springframework.cloud.verifier.twitter.place</basePackageForTests>
         <baseClassForTests>org.springframework.cloud.verifier.twitter.place.BaseMockMvcSpec</baseClassForTests>
     </configuration>
-</plugin>

87.2.7 Configuration Options

  • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, +</plugin>

83.2.7 Configuration Options

  • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, which is based on Spring’s MockMvc. It can also be changed to JaxRsClient or to Explicit for real HTTP calls.
  • basePackageForTests: Specifies the base package for all generated tests. If not set, the value is picked from baseClassForTests’s package and from `packageWithBaseClasses. @@ -377,7 +377,7 @@ the following options:

      groupid/artifactid where gropuid is slash separated.
    • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the local Maven artifacts should be reused.
    • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided, use the current Maven ones.
    • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
    • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
    • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
    • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.

    We cache only non-snapshot, explicitly provided versions (for example -+ or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

87.2.8 Single Base Class for All Tests

When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base ++ or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

83.2.8 Single Base Class for All Tests

When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base specification for all generated acceptance tests. In this class, you need to point to an endpoint, which should be verified.

package org.mycompany.tests
 
@@ -392,7 +392,7 @@ endpoint, which should be verified.
If you use Explicit mode, you can use a base class to initialize the whole tested app
 similarly, as you might find in regular integration tests. If you use the JAXRSCLIENT
 mode, this base class should also contain a protected WebTarget webTarget field. Right
-now, the only option to test the JAX-RS API is to start a web server.

87.2.9 Different base classes for contracts

If your base classes differ between contracts, you can tell the Spring Cloud Contract +now, the only option to test the JAX-RS API is to start a web server.

83.2.9 Different base classes for contracts

If your base classes differ between contracts, you can tell the Spring Cloud Contract plugin which class should get extended by the autogenerated tests. You have two options:

  • Follow a convention by providing the packageWithBaseClasses
  • provide explicit mapping via baseClassMappings

By Convention

The convention is such that if you have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set the value of the packageWithBaseClasses property to com.example.base, then Spring Cloud Contract @@ -425,7 +425,7 @@ name of the base class for the matched contract. You have to provide a list call * src/test/resources/contract/foo/

By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You can also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

87.2.10 Invoking generated tests

The Spring Cloud Contract Maven Plugin generates verification code in a directory called +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

83.2.10 Invoking generated tests

The Spring Cloud Contract Maven Plugin generates verification code in a directory called /generated-test-sources/contractVerifier and attaches this directory to testCompile goal.

For Groovy Spock code, use the following:

<plugin>
 	<groupId>org.codehaus.gmavenplus</groupId>
@@ -455,7 +455,7 @@ goal.
For Groovy Spock code, use the following:
</testSources>
 	</configuration>
 </plugin>
To ensure that provider side is compliant with defined contracts, you need to invoke
-mvn generateTest test.

87.2.11 Maven Plugin and STS

If you see the following exception while using STS:

STS Exception

When you click on the error marker you should see something like this:

 plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+mvn generateTest test.

83.2.11 Maven Plugin and STS

If you see the following exception while using STS:

STS Exception

When you click on the error marker you should see something like this:

 plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
@@ -492,7 +492,7 @@ goal.
For Groovy Spock code, use the following:
</plugin>
         </plugins>
     </pluginManagement>
-</build>

87.3 Stubs and Transitive Dependencies

The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One +</build>

83.3 Stubs and Transitive Dependencies

The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One problem that arises is that, when reusing the stubs, you can mistakenly import all of that stub’s dependencies. When building a Maven artifact, even though you have a couple of different jars, all of them share one pom:

├── github-webhook-0.0.1.BUILD-20160903.075506-1-stubs.jar
@@ -509,14 +509,14 @@ when you include the github-webhook stubs in anothe
 dependency gets downloaded by Stub Runner) then, since all of the dependencies are
 optional, they will not get downloaded.
Create a separate artifactid for the stubs
If you create a separate artifactid, then you can set it up in whatever way you wish.
 For example, you might decide to have no dependencies at all.
Exclude dependencies on the consumer side
As a consumer, if you add the stub dependency to your classpath, you can explicitly
-exclude the unwanted dependencies.

87.4 CI Server setup

When fetching stubs / contracts in a CI, shared environment, what might happen is that +exclude the unwanted dependencies.

83.4 CI Server setup

When fetching stubs / contracts in a CI, shared environment, what might happen is that both the producer and the consumer reuse the same local Maven repository. Due to this, the framework, responsible for downloading a stub JAR from remote location, can’t decide which JAR should be picked, local or remote one. That caused the "The artifact was found in the local repository but you have explicitly stated that it should be downloaded from a remote one" exception and failed the build.

For such cases we’re introducing the property mechanism:

  • via stubrunner.snapshot-check-skip system property
  • via STUBRUNNER_SNAPSHOT_CHECK_SKIP environment variable

if either of these values is set to true, then the stub downloader will not -verify the origin of the downloaded JAR.

87.5 Scenarios

You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to +verify the origin of the downloaded JAR.

83.5 Scenarios

You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to stick to the proper naming convention while creating your contracts. The convention requires including an order number followed by an underscore. This will work regardles of whether you’re working with YAML or Groovy. Example:

my_contracts_dir\
@@ -525,10 +525,10 @@ requires including an order number followed by an underscore. This will work reg
     2_showCart.groovy
     3_logout.groovy

Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

  1. login marked as Started pointing to…​
  2. showCart marked as Step1 pointing to…​
  3. logout marked as Step2 which will close the scenario.

More details about WireMock scenarios can be found at -http://wiremock.org/stateful-behaviour.html

Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

87.6 Docker Project

We’re publishing a springcloud/spring-cloud-contract Docker image +http://wiremock.org/stateful-behaviour.html

Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

83.6 Docker Project

We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

[Tip]Tip

The EXPLICIT mode means that the tests generated from contracts will send -real requests and not the mocked ones.

87.6.1 Short intro to Maven, JARs and Binary storage

Since the Docker image can be used by non JVM projects, it’s good to +real requests and not the mocked ones.

83.6.1 Short intro to Maven, JARs and Binary storage

Since the Docker image can be used by non JVM projects, it’s good to explain the basic terms behind Spring Cloud Contract packaging defaults.

Part of the following definitions were taken from the Maven Glossary

  • Project: Maven thinks in terms of projects. Everything that you will build are projects. Those projects follow a well defined “Project Object Model”. Projects can depend on other projects, @@ -555,7 +555,7 @@ like them to be available for others to download / reference or reuse. In case of the JVM world those artifacts would be JARs, for Ruby these are gems and for Docker those would be Docker images. You can store those artifacts in a manager. Examples of such managers can be Artifactory -or Nexus.

87.6.2 How it works

The image searches for contracts under the /contracts folder. +or Nexus.

83.6.2 How it works

The image searches for contracts under the /contracts folder. The output from running the tests will be available under /spring-cloud-contract/build folder (it’s useful for debugging purposes).

It’s enough for you to mount your contracts, pass the environment variables @@ -570,8 +570,8 @@ for group id foo.bar and artifact id .m2. Mount your local .m2 as a volume available at the container’s /root/.m2 path. You must not set both EXTERNAL_CONTRACTS_WORK_OFFLINE and EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL.

These environment variables are used when tests are executed:

  • APPLICATION_BASE_URL - url against which tests should be executed. Remember that it has to be accessible from the Docker container (e.g. localhost -will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application

87.6.3 Example of usage

Let’s take a look at a simple MVC application

$ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
-$ cd bookstore

The contracts are available under /contracts folder.

87.6.4 Server side (nodejs)

Since we want to run tests, we could just execute:

$ npm test

however, for learning purposes, let’s split it into pieces:

# Stop docker infra (nodejs, artifactory)
+will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application

    • 83.6.3 Example of usage

    Let’s take a look at a simple MVC application

    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
+$ cd bookstore

    The contracts are available under /contracts folder.

    83.6.4 Server side (nodejs)

    Since we want to run tests, we could just execute:

    $ npm test

    however, for learning purposes, let’s split it into pieces:

    # Stop docker infra (nodejs, artifactory)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
@@ -603,4 +603,4 @@ stateful situation
      • the contracts will be taken from /contracts folder.
      • the output of the test execution is available under
 node_modules/spring-cloud-contract/output.
  • the stubs will be uploaded to Artifactory. You can check them out
 under http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/ .
-The stubs will be here http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/bookstore-0.0.1.RELEASE-stubs.jar.

    • To see how the client side looks like check out the Section 89.9, “Stub Runner Docker” section.

    Prev Up Next
    86. Spring Cloud Contract FAQ Home 88. Spring Cloud Contract Verifier Messaging
    \ No newline at end of file +The stubs will be here http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/bookstore-0.0.1.RELEASE-stubs.jar.

    To see how the client side looks like check out the Section 85.9, “Stub Runner Docker” section.

    Prev Up Next
    82. Spring Cloud Contract FAQ Home 84. Spring Cloud Contract Verifier Messaging
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_contract_wiremock.html b/Edgware.SR3/multi/multi__spring_cloud_contract_wiremock.html index 90d1d600..0f8f0e54 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_contract_wiremock.html +++ b/Edgware.SR3/multi/multi__spring_cloud_contract_wiremock.html @@ -1,6 +1,6 @@ - 94. Spring Cloud Contract WireMock
    94. Spring Cloud Contract WireMock
    Prev Part XIII. Spring Cloud Contract Next

    94. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a + 90. Spring Cloud Contract WireMock

    90. Spring Cloud Contract WireMock
    Prev Part XII. Spring Cloud Contract Next

    90. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is @@ -30,7 +30,7 @@ your test. The following code shows an example:

    <
 server port can be bound in the test application context with the "wiremock.server.port"
 property. Using @AutoConfigureWireMock adds a bean of type WiremockConfiguration to
 your test application context, where it will be cached in between methods and classes
-having the same context, the same as for Spring integration tests.
    94.1 Registering Stubs Automatically
    If you use @AutoConfigureWireMock, it registers WireMock JSON stubs from the file
+having the same context, the same as for Spring integration tests.
    90.1 Registering Stubs Automatically
    If you use @AutoConfigureWireMock, it registers WireMock JSON stubs from the file
 system or classpath (by default, from file:src/test/resources/mappings). You can
 customize the locations using the stubs attribute in the annotation, which can be an
 Ant-style resource pattern or a directory. In the case of a directory, */.json is
@@ -49,7 +49,7 @@ public class WiremockImportApplicationTests {
 
 }
    [Note]Note

    Actually, WireMock always loads mappings from src/test/resources/mappings as well as the custom locations in the stubs attribute. To change this behavior, you can -also specify a files root as described in the next section of this document.

    94.2 Using Files to Specify the Stub Bodies

    WireMock can read response bodies from files on the classpath or the file system. In that +also specify a files root as described in the next section of this document.

    90.2 Using Files to Specify the Stub Bodies

    WireMock can read response bodies from files on the classpath or the file system. In that case, you can see in the JSON DSL that the response has a bodyFileName instead of a (literal) body. The files are resolved relative to a root directory (by default, src/test/resources/__files). To customize this location you can set the files @@ -60,7 +60,7 @@ supported. A list of values can be given, in which case WireMock resolves the fi that exists when it needs to find a response body.

    [Note]Note

    When you configure the files root, it also affects the automatic loading of stubs, because they come from the root location in a subdirectory called "mappings". The value of files has no -effect on the stubs loaded explicitly from the stubs attribute.

    94.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop +effect on the stubs loaded explicitly from the stubs attribute.

    90.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop the server. To do so, use the WireMockSpring convenience class to obtain an Options instance, as shown in the following example:

    @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@@ -86,7 +86,7 @@ instance, as shown in the following example:
    
 	}
 
 }
    The @ClassRule means that the server shuts down after all the methods in this class
-have been run.

    94.4 Relaxed SSL Validation for Rest Template

    WireMock lets you stub a "secure" server with an "https" URL protocol. If your +have been run.

    90.4 Relaxed SSL Validation for Rest Template

    WireMock lets you stub a "secure" server with an "https" URL protocol. If your application wants to contact that stub server in an integration test, it will find that the SSL certificates are not valid (the usual problem with self-installed certificates). The best option is often to re-configure the client to use "http". If that’s not an @@ -112,7 +112,7 @@ annotation or the stub runner. If you use the JUnit @Rule< classpath and it is selected by the RestTemplateBuilder and configured to ignore SSL errors. If you use the default java.net client, you do not need the annotation (but it won’t do any harm). There is no support currently for other clients, but it may be added -in future releases.

    94.5 WireMock and Spring MVC Mocks

    Spring Cloud Contract provides a convenience class that can load JSON WireMock stubs into +in future releases.

    90.5 WireMock and Spring MVC Mocks

    Spring Cloud Contract provides a convenience class that can load JSON WireMock stubs into a Spring MockRestServiceServer. The following code shows an example:

    @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment = WebEnvironment.NONE)
 public class WiremockForDocsMockServerApplicationTests {
@@ -143,7 +143,7 @@ pattern. The JSON format is the normal WireMock format, which you can read about
 WireMock website.
    Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as
 Spring Boot embedded servers, and Wiremock itself has "native" support for a particular
 version of Jetty (currently 9.2). To use the native Jetty, you need to add the native
-Wiremock dependencies and exclude the Spring Boot container (if there is one).

    94.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type +Wiremock dependencies and exclude the Spring Boot container (if there is one).

    90.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type in order to customize the WireMock configuration (e.g. add custom transformers). Example:

    		@Bean WireMockConfigurationCustomizer optionsCustomizer() {
 			return new WireMockConfigurationCustomizer() {
@@ -151,7 +151,7 @@ Example:
    		// perform your customization here
 				}
 			};
-		}

    94.7 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate + }

    90.7 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate documentation (for example in Asciidoctor format) for an HTTP API with Spring MockMvc or Rest Assured. At the same time that you generate documentation for your API, you can also generate WireMock stubs by using Spring Cloud Contract WireMock. To do so, write your @@ -237,7 +237,7 @@ available on the classpath (by stubs as JARs, for example). After that, you can create a stub using WireMock in a number of different ways, including by using @AutoConfigureWireMock(stubs="classpath:resource.json"), as described earlier in this -document.

    94.8 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST +document.

    90.8 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST Docs. If you do so in combination with Spring Cloud WireMock, you get both the contracts and the stubs.

    Why would you want to use this feature? Some people in the community asked questions about a situation in which they would like to move to DSL-based contract definition, @@ -287,4 +287,4 @@ Contract.make { } } }

    The generated document (formatted in Asciidoc in this case) contains a formatted -contract. The location of this file would be index/dsl-contract.adoc.

    Prev Up Next
    93. Using the Pluggable Architecture Home 95. Migrations
    \ No newline at end of file +contract. The location of this file would be index/dsl-contract.adoc.

    Prev Up Next
    89. Using the Pluggable Architecture Home 91. Migrations
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_for_cloud_foundry.html b/Edgware.SR3/multi/multi__spring_cloud_for_cloud_foundry.html index 4eba859c..bdb2d29b 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_for_cloud_foundry.html +++ b/Edgware.SR3/multi/multi__spring_cloud_for_cloud_foundry.html @@ -1,6 +1,6 @@ - Part XII. Spring Cloud for Cloud Foundry
    Part XII. Spring Cloud for Cloud Foundry
    Prev   Next

    Part XII. Spring Cloud for Cloud Foundry

    Spring Cloud for Cloudfoundry makes it easy to run + Part XI. Spring Cloud for Cloud Foundry

    Part XI. Spring Cloud for Cloud Foundry
    Prev   Next

    Part XI. Spring Cloud for Cloud Foundry

    Spring Cloud for Cloudfoundry makes it easy to run Spring Cloud apps in Cloud Foundry (the Platform as a Service). Cloud Foundry has the notion of a "service", which is @@ -16,4 +16,4 @@ implementation of Spring Cloud Commons DiscoveryClientDiscoveryClient directly or via a LoadBalancerClient (also *.url if you are not connecting to Pivotal Web Services).

    The first time you use it the discovery client might be slow owing to -the fact that it has to get an access token from Cloud Foundry.

    Prev   Next
    81. Configuring Authentication Downstream of a Zuul Proxy Home 82. Discovery
    \ No newline at end of file +the fact that it has to get an access token from Cloud Foundry.

    Prev   Next
    77. Configuring Authentication Downstream of a Zuul Proxy Home 78. Discovery
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_netflix.html b/Edgware.SR3/multi/multi__spring_cloud_netflix.html index 4076c020..1041d3db 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_netflix.html +++ b/Edgware.SR3/multi/multi__spring_cloud_netflix.html @@ -1,6 +1,6 @@ - Part III. Spring Cloud Netflix
    Part III. Spring Cloud Netflix
    Prev   Next

    Part III. Spring Cloud Netflix

    2.0.0.BUILD-SNAPSHOT

    This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration + Part III. Spring Cloud Netflix

    Part III. Spring Cloud Netflix
    Prev   Next

    Part III. Spring Cloud Netflix

    1.3.8.RELEASE

    This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The diff --git a/Edgware.SR3/multi/multi__spring_cloud_security.html b/Edgware.SR3/multi/multi__spring_cloud_security.html index 9befe897..68e811e4 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_security.html +++ b/Edgware.SR3/multi/multi__spring_cloud_security.html @@ -1,6 +1,6 @@ - Part XI. Spring Cloud Security

    Part XI. Spring Cloud Security
    Prev   Next

    Part XI. Spring Cloud Security

    Spring Cloud Security offers a set of primitives for building secure + Part X. Spring Cloud Security

    Part X. Spring Cloud Security
    Prev   Next

    Part X. Spring Cloud Security

    Spring Cloud Security offers a set of primitives for building secure applications and services with minimum fuss. A declarative model which can be heavily configured externally (or centrally) lends itself to the implementation of large systems of co-operating, remote components, @@ -8,4 +8,4 @@ usually with a central indentity management service. It is also extremely easy to use in a service platform like Cloud Foundry. Building on Spring Boot and Spring Security OAuth2 we can quickly create systems that implement common patterns like single sign on, token relay and token -exchange.

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    Prev   Next
    78. Encryption and Decryption Home 79. Quickstart
    \ No newline at end of file +exchange.

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    Prev   Next
    74. Distributed Configuration with Zookeeper Home 75. Quickstart
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_sleuth.html b/Edgware.SR3/multi/multi__spring_cloud_sleuth.html index fe973959..81b43737 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_sleuth.html +++ b/Edgware.SR3/multi/multi__spring_cloud_sleuth.html @@ -1,3 +1,3 @@ - Part VII. Spring Cloud Sleuth
    Part VII. Spring Cloud Sleuth
    Prev   Next

    Part VII. Spring Cloud Sleuth

    Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer

    2.0.0.BUILD-SNAPSHOT

    Prev   Next
    45. Broadcasting Your Own Events Home 46. Introduction
    \ No newline at end of file + Part VII. Spring Cloud Sleuth
    Part VII. Spring Cloud Sleuth
    Prev   Next

    Part VII. Spring Cloud Sleuth

    Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer

    1.3.8.RELEASE

    Prev   Next
    45. Broadcasting Your Own Events Home 46. Introduction
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__spring_cloud_vault.html b/Edgware.SR3/multi/multi__spring_cloud_vault.html index 4b9e0020..908f9b2b 100644 --- a/Edgware.SR3/multi/multi__spring_cloud_vault.html +++ b/Edgware.SR3/multi/multi__spring_cloud_vault.html @@ -1,3 +1,3 @@ - Part XIV. Spring Cloud Vault
    Part XIV. Spring Cloud Vault
    Prev   Next

    Part XIV. Spring Cloud Vault

    © 2016-2017 The original authors.

    [Note]Note

    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.

    Prev   Next
    96. Links Home 97. Quick Start
    \ No newline at end of file + Part XIII. Spring Cloud Vault
    Part XIII. Spring Cloud Vault
    Prev   Next

    Part XIII. Spring Cloud Vault

    © 2016-2017 The original authors.

    [Note]Note

    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.

    Prev   Next
    92. Links Home 93. Quick Start
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__stub_runner_for_messaging.html b/Edgware.SR3/multi/multi__stub_runner_for_messaging.html index 6498e69a..f6eecbc9 100644 --- a/Edgware.SR3/multi/multi__stub_runner_for_messaging.html +++ b/Edgware.SR3/multi/multi__stub_runner_for_messaging.html @@ -1,10 +1,10 @@ - 90. Stub Runner for Messaging
    90. Stub Runner for Messaging
    Prev Part XIII. Spring Cloud Contract Next

    90. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following + 86. Stub Runner for Messaging

    86. Stub Runner for Messaging
    Prev Part XII. Spring Cloud Contract Next

    86. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Apache Camel
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to define which one should be used. Let’s assume that you have both AMQP, Spring Cloud Stream and Spring Integration on the classpath. Then you need to set stubrunner.stream.enabled=false and stubrunner.integration.enabled=false. -That way the only remaining framework is Spring AMQP.

    90.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
+That way the only remaining framework is Spring AMQP.

    86.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
 
 import java.util.Collection;
 import java.util.Map;
@@ -45,10 +45,10 @@ That way the only remaining framework is Spring AMQP.
    Map<String, Collection<String>> labels(); }

    For convenience, the StubFinder interface extends StubTrigger, so you only need one -or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    90.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    90.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    90.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    90.1.4 Trigger All Messages

    stubFinder.trigger()

    90.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    86.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    86.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    86.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    86.1.4 Trigger All Messages

    stubFinder.trigger()

    86.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Apache Camel. For the provided artifacts, it automatically downloads the -stubs and registers the required routes.

    90.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

    90.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false +stubs and registers the required routes.

    86.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

    86.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the camelService application:

    └── .m2
     └── repository
@@ -107,10 +107,10 @@ receivedMessage.in.headers.get(
    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:input', new BookReturned('foo'), [sample: 'header'])
    You can listen to the output of the message sent to jms:output:
    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)
    The received message passes the following assertions:
    receivedMessage != null
 assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
 receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    90.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    86.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Integration. For the provided artifacts, it automatically downloads -the stubs and registers the required routes.

    90.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    90.3.2 Disabling the functionality

    If you need to disable this functionality, set the +the stubs and registers the required routes.

    86.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    86.3.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.integration.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the integrationService application:

    └── .m2
     └── repository
@@ -186,7 +186,7 @@ assertJsons(receivedMessage.payload)
 receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'input')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message passes the following assertions:

    receivedMessage != null
 assertJsons(receivedMessage.payload)
-receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    90.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    86.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Stream. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    [Warning]Warning

    If Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel and no such destination exists, the @@ -199,8 +199,8 @@ destination is resolved as a channel name.

    </dependency>

    Gradle.  

    testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

    -

    90.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    90.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false +

    86.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    86.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false property.

    Assume that you have the following Maven repository with a deployed stubs for the streamService application:

    └── .m2
     └── repository
@@ -267,7 +267,7 @@ receivedMessage.headers.get(destination:
    messaging.send(new BookReturned('foo'), [sample: 'header'], 'bookStorage')
    To listen to the output of the message sent to returnBook:
    Message<?> receivedMessage = messaging.receive('returnBook')
    The received message passes the following assertions:
    receivedMessage != null
 assertJsons(receivedMessage.payload)
 receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the output -destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    90.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to +destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    86.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to integrate with Spring AMQP’s Rabbit Template. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    The integration tries to work standalone (that is, without interaction with a running RabbitMQ message broker). It expects a RabbitTemplate on the application context and @@ -279,7 +279,7 @@ queues. Bindings connect an exchange to a queue. If message contracts are trigge Spring AMQP stub runner integration looks for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find message listeners bound to these queues. The message is triggered for all matching -message listeners.

    90.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and +message listeners.

    86.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. Remember to annotate your test class with @AutoConfigureStubRunner.

    [Important]Important

    If you already have Stream and Integration on the classpath, you need to disable them explicitly by setting the stubrunner.stream.enabled=false and @@ -351,4 +351,4 @@ definition is matched and invoked with the contract message.

    ConnectionFactory.
    To disable the mocked ConnectionFactory, set the following property:
 stubrunner.amqp.mockConnection=false
    stubrunner:
   amqp:
-    mockConnection: false
    Prev Up Next
    89. Spring Cloud Contract Stub Runner Home 91. Contract DSL
    
\ No newline at end of file
+    mockConnection: false
    Prev Up Next
    85. Spring Cloud Contract Stub Runner Home 87. Contract DSL
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi__using_the_pluggable_architecture.html b/Edgware.SR3/multi/multi__using_the_pluggable_architecture.html index 850c0ba8..6b4d8a1f 100644 --- a/Edgware.SR3/multi/multi__using_the_pluggable_architecture.html +++ b/Edgware.SR3/multi/multi__using_the_pluggable_architecture.html @@ -1,11 +1,11 @@ - 93. Using the Pluggable Architecture
    93. Using the Pluggable Architecture
    Prev Part XIII. Spring Cloud Contract Next

    93. Using the Pluggable Architecture

    You may encounter cases where you have your contracts have been defined in other formats, + 89. Using the Pluggable Architecture

    89. Using the Pluggable Architecture
    Prev Part XII. Spring Cloud Contract Next

    89. Using the Pluggable Architecture

    You may encounter cases where you have your contracts have been defined in other formats, such as YAML, RAML or PACT. In those cases, you still want to benefit from the automatic generation of tests and stubs. You can add your own implementation for generating both tests and stubs. Also, you can customize the way tests are generated (for example, you can generate tests for other languages) and the way stubs are generated (for example, you -can generate stubs for other HTTP server implementations).

    93.1 Custom Contract Converter

    The ContractConverter interface lets you register your own implementation of a contract +can generate stubs for other HTTP server implementations).

    89.1 Custom Contract Converter

    The ContractConverter interface lets you register your own implementation of a contract structure converter. The following code listing shows the ContractConverter interface:

    package org.springframework.cloud.contract.spec
 
 /**
@@ -47,9 +47,9 @@ structure converter. The following code listing shows the 
 conversion. Also, you must define how to perform that conversion in both directions.
    [Important]Important
    Once you create your implementation, you must create a
 /META-INF/spring.factories file in which you provide the fully qualified name of your
 implementation.
    The following example shows a typical spring.factories file:
    org.springframework.cloud.contract.spec.ContractConverter=\
-org.springframework.cloud.contract.verifier.converter.YamlContractConverter
    93.1.1 Pact Converter
    Spring Cloud Contract includes support for Pact representation of
+org.springframework.cloud.contract.verifier.converter.YamlContractConverter

    89.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of contracts. Instead of using the Groovy DSL, you can use Pact files. In this section, we -present how to add Pact support for your project.

    93.1.2 Pact Contract

    Consider following example of a Pact contract, which is a file under the +present how to add Pact support for your project.

    89.1.2 Pact Contract

    Consider following example of a Pact contract, which is a file under the src/test/resources/contracts folder.

    {
   "provider": {
     "name": "Provider"
@@ -103,7 +103,7 @@ present how to add Pact support for your project.
    "version": "2.4.18" } } -}

    The remainder of this section about using Pact refers to the preceding file.

    93.1.3 Pact for Producers

    On the producer side, you mustadd two additional dependencies to your plugin +}

    The remainder of this section about using Pact refers to the preceding file.

    89.1.3 Pact for Producers

    On the producer side, you mustadd two additional dependencies to your plugin configuration. One is the Spring Cloud Contract Pact support, and the other represents the current Pact version that you use.

    Maven.  

    <plugin>
@@ -173,7 +173,7 @@ test might be as follows:
    "Content-Type" : "application/vnd.fraud.v1+json;charset=UTF-8"
     }
   }
-}

    93.1.4 Pact for Consumers

    On the producer side, you must add two additional dependencies to your project +}

    89.1.4 Pact for Consumers

    On the producer side, you must add two additional dependencies to your project dependencies. One is the Spring Cloud Contract Pact support, and the other represents the current Pact version that you use.

    Maven.  

    <dependency>
@@ -190,7 +190,7 @@ current Pact version that you use.
    Maven. 
 
    Gradle. 
 
    testCompile "org.springframework.cloud:spring-cloud-contract-spec-pact"
 testCompile 'au.com.dius:pact-jvm-model:2.4.18'
    
-

    93.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the +

    89.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the way the verifier builds Java tests, you can register your own implementation.

    The SingleTestGenerator interface lets you register your own implementation. The following code listing shows the SingleTestGenerator interface:

    package org.springframework.cloud.contract.verifier.builder
 
@@ -225,7 +225,7 @@ following code listing shows the SingleTestGenerator
    Again, you must provide a spring.factories file, such as the one shown in the following
 example:
    org.springframework.cloud.contract.verifier.builder.SingleTestGenerator=/
-com.example.MyGenerator

    93.3 Using the Custom Stub Generator

    If you want to generate stubs for stub servers other than WireMock, you can plug in your +com.example.MyGenerator

    89.3 Using the Custom Stub Generator

    If you want to generate stubs for stub servers other than WireMock, you can plug in your own implementation of the StubGenerator interface. The following code listing shows the StubGenerator interface:

    package org.springframework.cloud.contract.verifier.converter
 
@@ -267,7 +267,7 @@ own implementation of the StubGenerator interface.
 example:
    # Stub converters
 org.springframework.cloud.contract.verifier.converter.StubGenerator=\
 org.springframework.cloud.contract.verifier.wiremock.DslToWireMockClientConverter
    The default implementation is the WireMock stub generation.
    [Tip]Tip
    You can provide multiple stub generator implementations. For example, from a single
-DSL, you can produce both WireMock stubs and Pact files.

    93.4 Using the Custom Stub Runner

    If you decide to use a custom stub generation, you also need a custom way of running +DSL, you can produce both WireMock stubs and Pact files.

    89.4 Using the Custom Stub Runner

    If you decide to use a custom stub generation, you also need a custom way of running stubs with your different stub provider.

    Assume that you use Moco to build your stubs and that you have written a stub generator and placed your stubs in a JAR file.

    In order for Stub Runner to know how to run your stubs, you have to define a custom HTTP Stub server implementation, which might resemble the following example:

    package org.springframework.cloud.contract.stubrunner.provider.moco
@@ -350,7 +350,7 @@ HTTP Stub server implementation, which might resemble the following example:
    
 }

    Then, you can register it in your spring.factories file, as shown in the following example:

    org.springframework.cloud.contract.stubrunner.HttpServerStub=\
 org.springframework.cloud.contract.stubrunner.provider.moco.MocoHttpServerStub

    Now you can run stubs with Moco.

    [Important]Important

    If you do not provide any implementation, then the default (WireMock) -implementation is used. If you provide more than one, the first one on the list is used.

    93.5 Using the Custom Stub Downloader

    You can customize the way your stubs are downloaded by creating an implementation of the +implementation is used. If you provide more than one, the first one on the list is used.

    89.5 Using the Custom Stub Downloader

    You can customize the way your stubs are downloaded by creating an implementation of the StubDownloaderBuilder interface, as shown in the following example:

    package com.example;
 
 class CustomStubDownloaderBuilder implements StubDownloaderBuilder {
@@ -377,4 +377,4 @@ com.example.CustomStubDownloaderBuilder

    Now you can pick a folder with t If you use the repositoryRoot property or the workOffline flag, then an Aether-based implementation that downloads stubs from a remote repository is used. If you do not provide these values, the ClasspathStubProvider (which will scan the classpath) is -used. If you provide more than one, then the first one on the list is used.

    Prev Up Next
    92. Customization Home 94. Spring Cloud Contract WireMock
    \ No newline at end of file +used. If you provide more than one, then the first one on the list is used.

    Prev Up Next
    88. Customization Home 90. Spring Cloud Contract WireMock
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_pr01.html b/Edgware.SR3/multi/multi_pr01.html index 83d7dd27..826b67cb 100644 --- a/Edgware.SR3/multi/multi_pr01.html +++ b/Edgware.SR3/multi/multi_pr01.html @@ -8,4 +8,4 @@ distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data -centres, and managed platforms such as Cloud Foundry.

    Version: 2.0.0.BUILD-SNAPSHOT

    Prev   Next
    Spring Cloud Home 1. Features
    \ No newline at end of file +centres, and managed platforms such as Cloud Foundry.

    Version: 1.3.8.RELEASE

    Prev   Next
    Spring Cloud Home 1. Features
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_spring-cloud-zookeeper-config.html b/Edgware.SR3/multi/multi_spring-cloud-zookeeper-config.html index 2a4baee0..b201315a 100644 --- a/Edgware.SR3/multi/multi_spring-cloud-zookeeper-config.html +++ b/Edgware.SR3/multi/multi_spring-cloud-zookeeper-config.html @@ -1,6 +1,6 @@ - 74. Distributed Configuration with Zookeeper
    74. Distributed Configuration with Zookeeper
    Prev Part IX. Spring Cloud Zookeeper Next

    74. Distributed Configuration with Zookeeper

    Zookeeper provides a hierarchical namespace that allows clients to store arbitrary data, such as configuration data. Spring Cloud Zookeeper Config is an alternative to the Config Server and Client. Configuration is loaded into the Spring Environment during the special "bootstrap" phase. Configuration is stored in the /config namespace by default. Multiple PropertySource instances are created based on the application’s name and the active profiles that mimicks the Spring Cloud Config order of resolving properties. For example, an application with the name "testApp" and with the "dev" profile will have the following property sources created:

    config/testApp,dev
+   74. Distributed Configuration with Zookeeper
    74. Distributed Configuration with Zookeeper
    Prev Part IX. Spring Cloud Zookeeper Next
    74. Distributed Configuration with Zookeeper
    Zookeeper provides a hierarchical namespace that allows clients to store arbitrary data, such as configuration data.  Spring Cloud Zookeeper Config is an alternative to the Config Server and Client.  Configuration is loaded into the Spring Environment during the special "bootstrap" phase.  Configuration is stored in the /config namespace by default.  Multiple PropertySource instances are created based on the application’s name and the active profiles that mimicks the Spring Cloud Config order of resolving properties.  For example, an application with the name "testApp" and with the "dev" profile will have the following property sources created:
    config/testApp,dev
 config/testApp
 config/application,dev
 config/application
    The most specific property source is at the top, with the least specific at the bottom.  Properties is the config/application namespace are applicable to all applications using zookeeper for configuration.  Properties in the config/testApp namespace are only available to the instances of the service named "testApp".
    Configuration is currently read on startup of the application.  Sending a HTTP POST to /refresh will cause the configuration to be reloaded.  Watching the configuration namespace (which Zookeeper supports) is not currently implemented, but will be a future addition to this project.
    74.1 How to activate
    Including a dependency on org.springframework.cloud:spring-cloud-starter-zookeeper-config will enable auto-configuration that will setup Spring Cloud Zookeeper Config.
    74.2 Customizing
    Zookeeper Config may be customized using the following properties:
    bootstrap.yml. 
@@ -40,4 +40,4 @@ comma-separated list set as the value of the property
 
    org.springframework.cloud.bootstrap.BootstrapConfiguration=\
 my.project.CustomCuratorFrameworkConfig,\
 my.project.DefaultCuratorFrameworkConfig
    
-
    Prev Up Next
    73. Spring Cloud Zookeeper Dependency Watcher Home Part X. Spring Boot Cloud CLI
    
\ No newline at end of file
+
    Unresolved directive in spring-cloud.adoc - include::../../../../cli/docs/src/main/asciidoc/spring-cloud-cli.adoc[]
    Prev Up Next
    73. Spring Cloud Zookeeper Dependency Watcher Home Part X. Spring Cloud Security
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_spring-cloud.html b/Edgware.SR3/multi/multi_spring-cloud.html index 248366b6..5e7a30e7 100644 --- a/Edgware.SR3/multi/multi_spring-cloud.html +++ b/Edgware.SR3/multi/multi_spring-cloud.html @@ -1,3 +1,3 @@ - Spring Cloud
    Spring Cloud
       Next

    Spring Cloud

    Table of Contents

    1. Features
    I. Cloud Native Applications
    2. Spring Cloud Context: Application Context Services
    2.1. The Bootstrap Application Context
    2.2. Application Context Hierarchies
    2.3. Changing the Location of Bootstrap Properties
    2.4. Overriding the Values of Remote Properties
    2.5. Customizing the Bootstrap Configuration
    2.6. Customizing the Bootstrap Property Sources
    2.7. Environment Changes
    2.8. Refresh Scope
    2.9. Encryption and Decryption
    2.10. Endpoints
    3. Spring Cloud Commons: Common Abstractions
    3.1. @EnableDiscoveryClient
    3.1.1. Health Indicator
    3.2. ServiceRegistry
    3.2.1. ServiceRegistry Auto-Registration
    3.2.2. Service Registry Actuator Endpoint
    3.3. Spring RestTemplate as a Load Balancer Client
    3.3.1. Retrying Failed Requests
    3.4. Multiple RestTemplate objects
    3.5. Ignore Network Interfaces
    3.6. HTTP Client Factories
    II. Spring Cloud Config
    4. Quick Start
    4.1. Client Side Usage
    5. Spring Cloud Config Server
    5.1. Environment Repository
    5.1.1. Git Backend
    Placeholders in Git URI
    Pattern Matching and Multiple Repositories
    Authentication
    Authentication with AWS CodeCommit
    Git SSH configuration using properties
    Placeholders in Git Search Paths
    Force pull in Git Repositories
    Deleting untracked branches in Git Repositories
    5.1.2. Version Control Backend Filesystem Use
    5.1.3. File System Backend
    5.1.4. Vault Backend
    Multiple Properties Sources
    5.1.5. Sharing Configuration With All Applications
    File Based Repositories
    Vault Server
    5.1.6. JDBC Backend
    5.1.7. Composite Environment Repositories
    Custom Composite Environment Repositories
    5.1.8. Property Overrides
    5.2. Health Indicator
    5.3. Security
    5.4. Encryption and Decryption
    5.5. Key Management
    5.6. Creating a Key Store for Testing
    5.7. Using Multiple Keys and Key Rotation
    5.8. Serving Encrypted Properties
    6. Serving Alternative Formats
    7. Serving Plain Text
    8. Embedding the Config Server
    9. Push Notifications and Spring Cloud Bus
    10. Spring Cloud Config Client
    10.1. Config First Bootstrap
    10.2. Discovery First Bootstrap
    10.3. Config Client Fail Fast
    10.4. Config Client Retry
    10.5. Locating Remote Configuration Resources
    10.6. Security
    10.6.1. Health Indicator
    10.6.2. Providing A Custom RestTemplate
    10.6.3. Vault
    10.7. Vault
    10.7.1. Nested Keys In Vault
    III. Spring Cloud Netflix
    11. Service Discovery: Eureka Clients
    11.1. How to Include Eureka Client
    11.2. Registering with Eureka
    11.3. Authenticating with the Eureka Server
    11.4. Status Page and Health Indicator
    11.5. Registering a Secure Application
    11.6. Eureka’s Health Checks
    11.7. Eureka Metadata for Instances and Clients
    11.7.1. Using Eureka on Cloudfoundry
    11.7.2. Using Eureka on AWS
    11.7.3. Changing the Eureka Instance ID
    11.8. Using the EurekaClient
    11.8.1. EurekaClient without Jersey
    11.9. Alternatives to the native Netflix EurekaClient
    11.10. Why is it so Slow to Register a Service?
    11.11. Zones
    12. Service Discovery: Eureka Server
    12.1. How to Include Eureka Server
    12.2. How to Run a Eureka Server
    12.3. High Availability, Zones and Regions
    12.4. Standalone Mode
    12.5. Peer Awareness
    12.6. Prefer IP Address
    13. Circuit Breaker: Hystrix Clients
    13.1. How to Include Hystrix
    13.2. Propagating the Security Context or using Spring Scopes
    13.3. Health Indicator
    13.4. Hystrix Metrics Stream
    14. Circuit Breaker: Hystrix Dashboard
    15. Hystrix Timeouts And Ribbon Clients
    15.1. How to Include Hystrix Dashboard
    15.2. Turbine
    15.3. Turbine Stream
    16. Client Side Load Balancer: Ribbon
    16.1. How to Include Ribbon
    16.2. Customizing the Ribbon Client
    16.3. Customizing default for all Ribbon Clients
    16.4. Customizing the Ribbon Client using properties
    16.5. Using Ribbon with Eureka
    16.6. Example: How to Use Ribbon Without Eureka
    16.7. Example: Disable Eureka use in Ribbon
    16.8. Using the Ribbon API Directly
    16.9. Caching of Ribbon Configuration
    16.10. How to Configure Hystrix thread pools
    16.11. How to Provide a Key to Ribbon’s IRule
    17. Declarative REST Client: Feign
    17.1. How to Include Feign
    17.2. Overriding Feign Defaults
    17.3. Creating Feign Clients Manually
    17.4. Feign Hystrix Support
    17.5. Feign Hystrix Fallbacks
    17.6. Feign and @Primary
    17.7. Feign Inheritance Support
    17.8. Feign request/response compression
    17.9. Feign logging
    18. External Configuration: Archaius
    19. Router and Filter: Zuul
    19.1. How to Include Zuul
    19.2. Embedded Zuul Reverse Proxy
    19.3. Zuul Http Client
    19.4. Cookies and Sensitive Headers
    19.5. Ignored Headers
    19.6. Management Endpoints
    19.6.1. Routes Endpoint
    19.6.2. Filters Endpoint
    19.7. Strangulation Patterns and Local Forwards
    19.8. Uploading Files through Zuul
    19.9. Query String Encoding
    19.10. Plain Embedded Zuul
    19.11. Disable Zuul Filters
    19.12. Providing Hystrix Fallbacks For Routes
    19.13. Zuul Timeouts
    19.13.1. Service Discovery Configuration
    19.13.2. URL Configuration
    19.14. Rewriting Location header
    19.15. Zuul Developer Guide
    19.15.1. The Zuul Servlet
    19.15.2. Zuul RequestContext
    19.15.3. @EnableZuulProxy vs. @EnableZuulServer
    19.15.4. @EnableZuulServer Filters
    19.15.5. @EnableZuulProxy Filters
    19.15.6. Custom Zuul Filter examples
    19.15.7. How to Write a Pre Filter
    19.15.8. How to Write a Route Filter
    19.15.9. How to Write a Post Filter
    19.15.10. How Zuul Errors Work
    19.15.11. Zuul Eager Application Context Loading
    20. Polyglot support with Sidecar
    21. RxJava with Spring MVC
    22. Metrics: Spectator, Servo, and Atlas
    22.1. Dimensional vs. Hierarchical Metrics
    22.2. Default Metrics Collection
    22.3. Metrics Collection: Spectator
    22.3.1. Spectator Counter
    22.3.2. Spectator Timer
    22.3.3. Spectator Gauge
    22.3.4. Spectator Distribution Summaries
    22.4. Metrics Collection: Servo
    22.4.1. Creating Servo Monitors
    22.5. Metrics Backend: Atlas
    22.5.1. Global tags
    22.5.2. Using Atlas
    22.6. Retrying Failed Requests
    22.6.1. BackOff Policies
    22.6.2. Configuration
    22.6.3. Zuul
    23. HTTP Clients
    IV. Spring Cloud Stream
    24. Introducing Spring Cloud Stream
    25. Main Concepts
    25.1. Application Model
    25.1.1. Fat JAR
    25.2. The Binder Abstraction
    25.3. Persistent Publish-Subscribe Support
    25.4. Consumer Groups
    25.4.1. Durability
    25.5. Partitioning Support
    26. Programming Model
    26.1. Declaring and Binding Channels
    26.1.1. Triggering Binding Via @EnableBinding
    26.1.2. @Input and @Output
    Customizing Channel Names
    Source, Sink, and Processor
    26.1.3. Accessing Bound Channels
    Injecting the Bound Interfaces
    Injecting Channels Directly
    26.1.4. Producing and Consuming Messages
    Native Spring Integration Support
    Spring Integration Error Channel Support
    Message Channel Binders and Error Channels
    Using @StreamListener for Automatic Content Type Handling
    Using @StreamListener for dispatching messages to multiple methods
    26.1.5. Reactive Programming Support
    Reactor-based handlers
    RxJava 1.x support
    Reactive Sources
    26.1.6. Aggregation
    Configuring aggregate application
    Configuring binding service properties for non self contained aggregate application
    27. Binders
    27.1. Producers and Consumers
    27.2. Binder SPI
    27.3. Binder Detection
    27.3.1. Classpath Detection
    27.4. Multiple Binders on the Classpath
    27.5. Connecting to Multiple Systems
    27.6. Binder configuration properties
    28. Configuration Options
    28.1. Spring Cloud Stream Properties
    28.2. Binding Properties
    28.2.1. Properties for Use of Spring Cloud Stream
    28.2.2. Consumer properties
    28.2.3. Producer Properties
    28.3. Using dynamically bound destinations
    29. Content Type and Transformation
    29.1. MIME types
    29.2. MIME types and Java types
    29.3. Customizing message conversion
    29.4. @StreamListener and Message Conversion
    30. Schema evolution support
    30.1. Apache Avro Message Converters
    30.2. Converters with schema support
    30.3. Schema Registry Support
    30.4. Schema Registry Server
    30.4.1. Schema Registry Server API
    POST /
    GET /{subject}/{format}/{version}
    GET /{subject}/{format}
    GET /schemas/{id}
    DELETE /{subject}/{format}/{version}
    DELETE /schemas/{id}
    DELETE /{subject}
    30.5. Schema Registry Client
    30.5.1. Using Confluent’s Schema Registry
    30.5.2. Schema Registry Client properties
    30.6. Avro Schema Registry Client Message Converters
    30.6.1. Avro Schema Registry Message Converter properties
    30.7. Schema Registration and Resolution
    30.7.1. Schema Registration Process (Serialization)
    30.7.2. Schema Resolution Process (Deserialization)
    31. Inter-Application Communication
    31.1. Connecting Multiple Application Instances
    31.2. Instance Index and Instance Count
    31.3. Partitioning
    31.3.1. Configuring Output Bindings for Partitioning
    Spring-managed custom PartitionKeyExtractorClass implementations
    Configuring Input Bindings for Partitioning
    32. Testing
    32.1. Disabling the test binder autoconfiguration
    33. Health Indicator
    34. Metrics Emitter
    35. Samples
    36. Getting Started
    36.1. Deploying Stream applications on CloudFoundry
    V. Binder Implementations
    37. Apache Kafka Binder
    37.1. Usage
    37.2. Apache Kafka Binder Overview
    37.3. Configuration Options
    37.3.1. Kafka Binder Properties
    37.3.2. Kafka Consumer Properties
    37.3.3. Kafka Producer Properties
    37.3.4. Usage examples
    Example: Setting autoCommitOffset false and relying on manual acking.
    Example: security configuration
    Using the binder with Apache Kafka 0.10
    Excluding Kafka broker jar from the classpath of the binder based application
    37.4. Kafka Streams Binding Capabilities of Spring Cloud Stream
    37.4.1. Usage example of high level streams DSL
    37.4.2. Support for interactive queries
    37.4.3. Kafka Streams properties
    37.5. Error Channels
    37.6. Kafka Metrics
    37.7. Dead-Letter Topic Processing
    38. RabbitMQ Binder
    38.1. Usage
    38.2. RabbitMQ Binder Overview
    38.3. Configuration Options
    38.3.1. RabbitMQ Binder Properties
    38.3.2. RabbitMQ Consumer Properties
    38.3.3. Rabbit Producer Properties
    38.4. Retry With the RabbitMQ Binder
    38.4.1. Overview
    38.4.2. Putting it All Together
    38.5. Error Channels
    38.6. Dead-Letter Queue Processing
    38.6.1. Non-Partitioned Destinations
    38.6.2. Partitioned Destinations
    republishToDlq=false
    republishToDlq=true
    VI. Spring Cloud Bus
    39. Quick Start
    40. Addressing an Instance
    41. Addressing all instances of a service
    42. Application Context ID must be unique
    43. Customizing the Message Broker
    44. Tracing Bus Events
    45. Broadcasting Your Own Events
    45.1. Registering events in custom packages
    VII. Spring Cloud Sleuth
    46. Introduction
    46.1. Terminology
    46.2. Purpose
    46.2.1. Distributed tracing with Zipkin
    46.2.2. Visualizing errors
    46.2.3. Live examples
    46.2.4. Log correlation
    JSON Logback with Logstash
    46.2.5. Propagating Span Context
    Baggage vs. Span Tags
    46.3. Adding to the project
    46.3.1. Only Sleuth (log correlation)
    46.3.2. Sleuth with Zipkin via HTTP
    46.3.3. Sleuth with Zipkin via RabbitMQ or Kafka
    47. Additional resources
    48. Features
    49. Sampling
    50. Instrumentation
    51. Span lifecycle
    51.1. Creating and closing spans
    51.2. Continuing spans
    51.3. Creating spans with an explicit parent
    52. Naming spans
    52.1. @SpanName annotation
    52.2. toString() method
    53. Managing spans with annotations
    53.1. Rationale
    53.2. Creating new spans
    53.3. Continuing spans
    53.4. More advanced tag setting
    53.4.1. Custom extractor
    53.4.2. Resolving expressions for value
    53.4.3. Using toString method
    54. Customizations
    54.1. Spring Integration
    54.2. HTTP
    54.3. Example
    54.4. TraceFilter
    54.5. Custom SA tag in Zipkin
    54.6. Custom service name
    54.7. Customization of reported spans
    54.8. Host locator
    55. Sending spans to Zipkin
    56. Span Data as Messages
    56.1. Zipkin Consumer
    56.2. Custom Consumer
    57. Metrics
    58. Integrations
    58.1. Runnable and Callable
    58.2. Hystrix
    58.2.1. Custom Concurrency Strategy
    58.2.2. Manual Command setting
    58.3. RxJava
    58.4. HTTP integration
    58.4.1. HTTP Filter
    58.4.2. HandlerInterceptor
    58.4.3. Async Servlet support
    58.5. HTTP client integration
    58.5.1. Synchronous Rest Template
    58.5.2. Asynchronous Rest Template
    Multiple Asynchronous Rest Templates
    58.5.3. Traverson
    58.6. Feign
    58.7. Asynchronous communication
    58.7.1. @Async annotated methods
    58.7.2. @Scheduled annotated methods
    58.7.3. Executor, ExecutorService and ScheduledExecutorService
    Customization of Executors
    58.8. Messaging
    58.9. Zuul
    58.10. Spring Cloud Function
    59. Running examples
    VIII. Spring Cloud Consul
    60. Install Consul
    61. Consul Agent
    62. Service Discovery with Consul
    62.1. How to activate
    62.2. Registering with Consul
    62.3. HTTP Health Check
    62.3.1. Metadata and Consul tags
    62.3.2. Making the Consul Instance ID Unique
    62.4. Looking up services
    62.4.1. Using Ribbon
    62.4.2. Using the DiscoveryClient
    63. Distributed Configuration with Consul
    63.1. How to activate
    63.2. Customizing
    63.3. Config Watch
    63.4. YAML or Properties with Config
    63.5. git2consul with Config
    63.6. Fail Fast
    64. Consul Retry
    65. Spring Cloud Bus with Consul
    65.1. How to activate
    66. Circuit Breaker with Hystrix
    67. Hystrix metrics aggregation with Turbine and Consul
    IX. Spring Cloud Zookeeper
    68. Install Zookeeper
    69. Service Discovery with Zookeeper
    69.1. How to activate
    69.2. Registering with Zookeeper
    69.3. Using the DiscoveryClient
    70. Using Spring Cloud Zookeeper with Spring Cloud Netflix Components
    70.1. Ribbon with Zookeeper
    71. Spring Cloud Zookeeper and Service Registry
    71.1. Instance Status
    72. Zookeeper Dependencies
    72.1. Using the Zookeeper Dependencies
    72.2. How to activate Zookeeper Dependencies
    72.3. Setting up Zookeeper Dependencies
    72.3.1. Aliases
    72.3.2. Path
    72.3.3. Load balancer type
    72.3.4. Content-Type template and version
    72.3.5. Default headers
    72.3.6. Obligatory dependencies
    72.3.7. Stubs
    72.4. Configuring Spring Cloud Zookeeper Dependencies
    73. Spring Cloud Zookeeper Dependency Watcher
    73.1. How to activate
    73.2. Registering a listener
    73.3. Presence Checker
    74. Distributed Configuration with Zookeeper
    74.1. How to activate
    74.2. Customizing
    74.3. ACLs
    X. Spring Boot Cloud CLI
    75. Installation
    76. Running Spring Cloud Services in Development
    76.1. Adding Additional Applications
    77. Writing Groovy Scripts and Running Applications
    78. Encryption and Decryption
    XI. Spring Cloud Security
    79. Quickstart
    79.1. OAuth2 Single Sign On
    79.2. OAuth2 Protected Resource
    80. More Detail
    80.1. Single Sign On
    80.2. Token Relay
    80.2.1. Client Token Relay
    80.2.2. Client Token Relay in Zuul Proxy
    80.2.3. Resource Server Token Relay
    81. Configuring Authentication Downstream of a Zuul Proxy
    XII. Spring Cloud for Cloud Foundry
    82. Discovery
    83. Single Sign On
    XIII. Spring Cloud Contract
    84. Spring Cloud Contract
    85. Spring Cloud Contract Verifier Introduction
    85.1. Why a Contract Verifier?
    85.1.1. Testing issues
    85.2. Purposes
    85.3. How It Works
    85.3.1. Defining the contract
    85.3.2. Client Side
    85.3.3. Server Side
    85.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    85.4.1. Technical note
    85.4.2. Consumer side (Loan Issuance)
    85.4.3. Producer side (Fraud Detection server)
    85.4.4. Consumer Side (Loan Issuance) Final Step
    85.5. Dependencies
    85.6. Additional Links
    85.6.1. Spring Cloud Contract video
    85.6.2. Readings
    85.7. Samples
    86. Spring Cloud Contract FAQ
    86.1. Why use Spring Cloud Contract Verifier and not X ?
    86.2. I don’t want to write a contract in Groovy!
    86.3. What is this value(consumer(), producer()) ?
    86.4. How to do Stubs versioning?
    86.4.1. API Versioning
    86.4.2. JAR versioning
    86.4.3. Dev or prod stubs
    86.5. Common repo with contracts
    86.5.1. Repo structure
    86.5.2. Workflow
    86.5.3. Consumer
    86.5.4. Producer
    86.6. Can I have multiple base classes for tests?
    86.7. How can I debug the request/response being sent by the generated tests client?
    86.7.1. How can I debug the mapping/request/response being sent by WireMock?
    86.7.2. How can I see what got registered in the HTTP server stub?
    86.7.3. Can I reference the request from the response?
    86.7.4. Can I reference text from file?
    87. Spring Cloud Contract Verifier Setup
    87.1. Gradle Project
    87.1.1. Prerequisites
    87.1.2. Add Gradle Plugin with Dependencies
    87.1.3. Gradle and Rest Assured 2.0
    87.1.4. Snapshot Versions for Gradle
    87.1.5. Add stubs
    87.1.6. Run the Plugin
    87.1.7. Default Setup
    87.1.8. Configure Plugin
    87.1.9. Configuration Options
    87.1.10. Single Base Class for All Tests
    87.1.11. Different Base Classes for Contracts
    87.1.12. Invoking Generated Tests
    87.1.13. Spring Cloud Contract Verifier on the Consumer Side
    87.2. Maven Project
    87.2.1. Add maven plugin
    87.2.2. Maven and Rest Assured 2.0
    87.2.3. Snapshot versions for Maven
    87.2.4. Add stubs
    87.2.5. Run plugin
    87.2.6. Configure plugin
    87.2.7. Configuration Options
    87.2.8. Single Base Class for All Tests
    87.2.9. Different base classes for contracts
    87.2.10. Invoking generated tests
    87.2.11. Maven Plugin and STS
    87.3. Stubs and Transitive Dependencies
    87.4. CI Server setup
    87.5. Scenarios
    87.6. Docker Project
    87.6.1. Short intro to Maven, JARs and Binary storage
    87.6.2. How it works
    Environment Variables
    87.6.3. Example of usage
    87.6.4. Server side (nodejs)
    88. Spring Cloud Contract Verifier Messaging
    88.1. Integrations
    88.2. Manual Integration Testing
    88.3. Publisher-Side Test Generation
    88.3.1. Scenario 1: No Input Message
    88.3.2. Scenario 2: Output Triggered by Input
    88.3.3. Scenario 3: No Output Message
    88.4. Consumer Stub Generation
    89. Spring Cloud Contract Stub Runner
    89.1. Snapshot versions
    89.2. Publishing Stubs as JARs
    89.3. Stub Runner Core
    89.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    89.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    89.4. Stub Runner JUnit Rule
    89.4.1. Maven settings
    89.4.2. Providing fixed ports
    89.4.3. Fluent API
    89.4.4. Stub Runner with Spring
    89.5. Stub Runner Spring Cloud
    89.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    89.5.2. Additional Configuration
    89.6. Stub Runner Boot Application
    89.6.1. How to use it?
    Stub Runner Server
    Stub Runner Server Fat Jar
    Spring Cloud CLI
    89.6.2. Endpoints
    HTTP
    Messaging
    89.6.3. Example
    89.6.4. Stub Runner Boot with Service Discovery
    89.7. Stubs Per Consumer
    89.8. Common
    89.8.1. Common Properties for JUnit and Spring
    89.8.2. Stub Runner Stubs IDs
    89.9. Stub Runner Docker
    89.9.1. How to use it
    89.9.2. Example of client side usage in a non JVM project
    90. Stub Runner for Messaging
    90.1. Stub triggering
    90.1.1. Trigger by Label
    90.1.2. Trigger by Group and Artifact Ids
    90.1.3. Trigger by Artifact Ids
    90.1.4. Trigger All Messages
    90.2. Stub Runner Camel
    90.2.1. Adding the Runner to the Project
    90.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.3. Stub Runner Integration
    90.3.1. Adding the Runner to the Project
    90.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.4. Stub Runner Stream
    90.4.1. Adding the Runner to the Project
    90.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.5. Stub Runner Spring AMQP
    90.5.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    91. Contract DSL
    91.1. Limitations
    91.2. Common Top-Level elements
    91.2.1. Description
    91.2.2. Name
    91.2.3. Ignoring Contracts
    91.2.4. Passing Values from Files
    91.2.5. HTTP Top-Level Elements
    91.3. Request
    91.4. Response
    91.5. Dynamic properties
    91.5.1. Dynamic properties inside the body
    91.5.2. Regular expressions
    91.5.3. Passing Optional Parameters
    91.5.4. Executing Custom Methods on the Server Side
    91.5.5. Referencing the Request from the Response
    91.5.6. Registering Your Own WireMock Extension
    91.5.7. Dynamic Properties in the Matchers Sections
    91.6. JAX-RS Support
    91.7. Async Support
    91.8. Working with Context Paths
    91.9. Messaging Top-Level Elements
    91.9.1. Output Triggered by a Method
    91.9.2. Output Triggered by a Message
    91.9.3. Consumer/Producer
    91.9.4. Common
    91.10. Multiple Contracts in One File
    92. Customization
    92.1. Extending the DSL
    92.1.1. Common JAR
    92.1.2. Adding the Dependency to the Project
    92.1.3. Test the Dependency in the Project’s Dependencies
    92.1.4. Test a Dependency in the Plugin’s Dependencies
    92.1.5. Referencing classes in DSLs
    93. Using the Pluggable Architecture
    93.1. Custom Contract Converter
    93.1.1. Pact Converter
    93.1.2. Pact Contract
    93.1.3. Pact for Producers
    93.1.4. Pact for Consumers
    93.2. Using the Custom Test Generator
    93.3. Using the Custom Stub Generator
    93.4. Using the Custom Stub Runner
    93.5. Using the Custom Stub Downloader
    94. Spring Cloud Contract WireMock
    94.1. Registering Stubs Automatically
    94.2. Using Files to Specify the Stub Bodies
    94.3. Alternative: Using JUnit Rules
    94.4. Relaxed SSL Validation for Rest Template
    94.5. WireMock and Spring MVC Mocks
    94.6. Customization of WireMock configuration
    94.7. Generating Stubs using REST Docs
    94.8. Generating Contracts by Using REST Docs
    95. Migrations
    95.1. 1.0.x → 1.1.x
    95.1.1. New structure of generated stubs
    95.2. 1.1.x → 1.2.x
    95.2.1. Custom HttpServerStub
    95.2.2. New packages for generated tests
    95.2.3. New Methods in TemplateProcessor
    95.2.4. RestAssured 3.0
    96. Links
    XIV. Spring Cloud Vault
    97. Quick Start
    98. Client Side Usage
    98.1. Authentication
    99. Authentication methods
    99.1. Token authentication
    99.2. AppId authentication
    99.2.1. Custom UserId
    99.3. AppRole authentication
    99.4. AWS-EC2 authentication
    99.5. AWS-IAM authentication
    99.6. TLS certificate authentication
    99.7. Cubbyhole authentication
    99.8. Kubernetes authentication
    100. Secret Backends
    100.1. Generic Backend
    100.2. Consul
    100.3. RabbitMQ
    100.4. AWS
    101. Database backends
    101.1. Apache Cassandra
    101.2. MongoDB
    101.3. MySQL
    101.4. PostgreSQL
    102. Configure PropertySourceLocator behavior
    103. Service Registry Configuration
    104. Vault Client Fail Fast
    105. Vault Client SSL configuration
    106. Lease lifecycle management (renewal and revocation)
    XV. Appendix: Compendium of Configuration Properties
       Next
       
    \ No newline at end of file + Spring Cloud
    Spring Cloud
       Next

    Spring Cloud

    Table of Contents

    1. Features
    I. Cloud Native Applications
    2. Spring Cloud Context: Application Context Services
    2.1. The Bootstrap Application Context
    2.2. Application Context Hierarchies
    2.3. Changing the Location of Bootstrap Properties
    2.4. Overriding the Values of Remote Properties
    2.5. Customizing the Bootstrap Configuration
    2.6. Customizing the Bootstrap Property Sources
    2.7. Environment Changes
    2.8. Refresh Scope
    2.9. Encryption and Decryption
    2.10. Endpoints
    3. Spring Cloud Commons: Common Abstractions
    3.1. @EnableDiscoveryClient
    3.1.1. Health Indicator
    3.2. ServiceRegistry
    3.2.1. ServiceRegistry Auto-Registration
    3.2.2. Service Registry Actuator Endpoint
    3.3. Spring RestTemplate as a Load Balancer Client
    3.3.1. Retrying Failed Requests
    3.4. Multiple RestTemplate objects
    3.5. Ignore Network Interfaces
    3.6. HTTP Client Factories
    II. Spring Cloud Config
    4. Quick Start
    4.1. Client Side Usage
    5. Spring Cloud Config Server
    5.1. Environment Repository
    5.1.1. Git Backend
    Placeholders in Git URI
    Pattern Matching and Multiple Repositories
    Authentication
    Authentication with AWS CodeCommit
    Git SSH configuration using properties
    Placeholders in Git Search Paths
    Force pull in Git Repositories
    Deleting untracked branches in Git Repositories
    5.1.2. Version Control Backend Filesystem Use
    5.1.3. File System Backend
    5.1.4. Vault Backend
    Multiple Properties Sources
    5.1.5. Sharing Configuration With All Applications
    File Based Repositories
    Vault Server
    5.1.6. JDBC Backend
    5.1.7. Composite Environment Repositories
    Custom Composite Environment Repositories
    5.1.8. Property Overrides
    5.2. Health Indicator
    5.3. Security
    5.4. Encryption and Decryption
    5.5. Key Management
    5.6. Creating a Key Store for Testing
    5.7. Using Multiple Keys and Key Rotation
    5.8. Serving Encrypted Properties
    6. Serving Alternative Formats
    7. Serving Plain Text
    8. Embedding the Config Server
    9. Push Notifications and Spring Cloud Bus
    10. Spring Cloud Config Client
    10.1. Config First Bootstrap
    10.2. Discovery First Bootstrap
    10.3. Config Client Fail Fast
    10.4. Config Client Retry
    10.5. Locating Remote Configuration Resources
    10.6. Security
    10.6.1. Health Indicator
    10.6.2. Providing A Custom RestTemplate
    10.6.3. Vault
    10.7. Vault
    10.7.1. Nested Keys In Vault
    III. Spring Cloud Netflix
    11. Service Discovery: Eureka Clients
    11.1. How to Include Eureka Client
    11.2. Registering with Eureka
    11.3. Authenticating with the Eureka Server
    11.4. Status Page and Health Indicator
    11.5. Registering a Secure Application
    11.6. Eureka’s Health Checks
    11.7. Eureka Metadata for Instances and Clients
    11.7.1. Using Eureka on Cloudfoundry
    11.7.2. Using Eureka on AWS
    11.7.3. Changing the Eureka Instance ID
    11.8. Using the EurekaClient
    11.8.1. EurekaClient without Jersey
    11.9. Alternatives to the native Netflix EurekaClient
    11.10. Why is it so Slow to Register a Service?
    11.11. Zones
    12. Service Discovery: Eureka Server
    12.1. How to Include Eureka Server
    12.2. How to Run a Eureka Server
    12.3. High Availability, Zones and Regions
    12.4. Standalone Mode
    12.5. Peer Awareness
    12.6. Prefer IP Address
    13. Circuit Breaker: Hystrix Clients
    13.1. How to Include Hystrix
    13.2. Propagating the Security Context or using Spring Scopes
    13.3. Health Indicator
    13.4. Hystrix Metrics Stream
    14. Circuit Breaker: Hystrix Dashboard
    15. Hystrix Timeouts And Ribbon Clients
    15.1. How to Include Hystrix Dashboard
    15.2. Turbine
    15.3. Turbine Stream
    16. Client Side Load Balancer: Ribbon
    16.1. How to Include Ribbon
    16.2. Customizing the Ribbon Client
    16.3. Customizing default for all Ribbon Clients
    16.4. Customizing the Ribbon Client using properties
    16.5. Using Ribbon with Eureka
    16.6. Example: How to Use Ribbon Without Eureka
    16.7. Example: Disable Eureka use in Ribbon
    16.8. Using the Ribbon API Directly
    16.9. Caching of Ribbon Configuration
    16.10. How to Configure Hystrix thread pools
    16.11. How to Provide a Key to Ribbon’s IRule
    17. Declarative REST Client: Feign
    17.1. How to Include Feign
    17.2. Overriding Feign Defaults
    17.3. Creating Feign Clients Manually
    17.4. Feign Hystrix Support
    17.5. Feign Hystrix Fallbacks
    17.6. Feign and @Primary
    17.7. Feign Inheritance Support
    17.8. Feign request/response compression
    17.9. Feign logging
    18. External Configuration: Archaius
    19. Router and Filter: Zuul
    19.1. How to Include Zuul
    19.2. Embedded Zuul Reverse Proxy
    19.3. Zuul Http Client
    19.4. Cookies and Sensitive Headers
    19.5. Ignored Headers
    19.6. Management Endpoints
    19.6.1. Routes Endpoint
    19.6.2. Filters Endpoint
    19.7. Strangulation Patterns and Local Forwards
    19.8. Uploading Files through Zuul
    19.9. Query String Encoding
    19.10. Plain Embedded Zuul
    19.11. Disable Zuul Filters
    19.12. Providing Hystrix Fallbacks For Routes
    19.13. Zuul Timeouts
    19.13.1. Service Discovery Configuration
    19.13.2. URL Configuration
    19.14. Rewriting Location header
    19.15. Zuul Developer Guide
    19.15.1. The Zuul Servlet
    19.15.2. Zuul RequestContext
    19.15.3. @EnableZuulProxy vs. @EnableZuulServer
    19.15.4. @EnableZuulServer Filters
    19.15.5. @EnableZuulProxy Filters
    19.15.6. Custom Zuul Filter examples
    19.15.7. How to Write a Pre Filter
    19.15.8. How to Write a Route Filter
    19.15.9. How to Write a Post Filter
    19.15.10. How Zuul Errors Work
    19.15.11. Zuul Eager Application Context Loading
    20. Polyglot support with Sidecar
    21. RxJava with Spring MVC
    22. Metrics: Spectator, Servo, and Atlas
    22.1. Dimensional vs. Hierarchical Metrics
    22.2. Default Metrics Collection
    22.3. Metrics Collection: Spectator
    22.3.1. Spectator Counter
    22.3.2. Spectator Timer
    22.3.3. Spectator Gauge
    22.3.4. Spectator Distribution Summaries
    22.4. Metrics Collection: Servo
    22.4.1. Creating Servo Monitors
    22.5. Metrics Backend: Atlas
    22.5.1. Global tags
    22.5.2. Using Atlas
    22.6. Retrying Failed Requests
    22.6.1. BackOff Policies
    22.6.2. Configuration
    22.6.3. Zuul
    23. HTTP Clients
    IV. Spring Cloud Stream
    24. Introducing Spring Cloud Stream
    25. Main Concepts
    25.1. Application Model
    25.1.1. Fat JAR
    25.2. The Binder Abstraction
    25.3. Persistent Publish-Subscribe Support
    25.4. Consumer Groups
    25.4.1. Durability
    25.5. Partitioning Support
    26. Programming Model
    26.1. Declaring and Binding Channels
    26.1.1. Triggering Binding Via @EnableBinding
    26.1.2. @Input and @Output
    Customizing Channel Names
    Source, Sink, and Processor
    26.1.3. Accessing Bound Channels
    Injecting the Bound Interfaces
    Injecting Channels Directly
    26.1.4. Producing and Consuming Messages
    Native Spring Integration Support
    Spring Integration Error Channel Support
    Message Channel Binders and Error Channels
    Using @StreamListener for Automatic Content Type Handling
    Using @StreamListener for dispatching messages to multiple methods
    26.1.5. Reactive Programming Support
    Reactor-based handlers
    RxJava 1.x support
    Reactive Sources
    26.1.6. Aggregation
    Configuring aggregate application
    Configuring binding service properties for non self contained aggregate application
    27. Binders
    27.1. Producers and Consumers
    27.2. Binder SPI
    27.3. Binder Detection
    27.3.1. Classpath Detection
    27.4. Multiple Binders on the Classpath
    27.5. Connecting to Multiple Systems
    27.6. Binder configuration properties
    28. Configuration Options
    28.1. Spring Cloud Stream Properties
    28.2. Binding Properties
    28.2.1. Properties for Use of Spring Cloud Stream
    28.2.2. Consumer properties
    28.2.3. Producer Properties
    28.3. Using dynamically bound destinations
    29. Content Type and Transformation
    29.1. MIME types
    29.2. MIME types and Java types
    29.3. Customizing message conversion
    29.4. @StreamListener and Message Conversion
    30. Schema evolution support
    30.1. Apache Avro Message Converters
    30.2. Converters with schema support
    30.3. Schema Registry Support
    30.4. Schema Registry Server
    30.4.1. Schema Registry Server API
    POST /
    GET /{subject}/{format}/{version}
    GET /{subject}/{format}
    GET /schemas/{id}
    DELETE /{subject}/{format}/{version}
    DELETE /schemas/{id}
    DELETE /{subject}
    30.5. Schema Registry Client
    30.5.1. Using Confluent’s Schema Registry
    30.5.2. Schema Registry Client properties
    30.6. Avro Schema Registry Client Message Converters
    30.6.1. Avro Schema Registry Message Converter properties
    30.7. Schema Registration and Resolution
    30.7.1. Schema Registration Process (Serialization)
    30.7.2. Schema Resolution Process (Deserialization)
    31. Inter-Application Communication
    31.1. Connecting Multiple Application Instances
    31.2. Instance Index and Instance Count
    31.3. Partitioning
    31.3.1. Configuring Output Bindings for Partitioning
    Spring-managed custom PartitionKeyExtractorClass implementations
    Configuring Input Bindings for Partitioning
    32. Testing
    32.1. Disabling the test binder autoconfiguration
    33. Health Indicator
    34. Metrics Emitter
    35. Samples
    36. Getting Started
    36.1. Deploying Stream applications on CloudFoundry
    V. Binder Implementations
    37. Apache Kafka Binder
    37.1. Usage
    37.2. Apache Kafka Binder Overview
    37.3. Configuration Options
    37.3.1. Kafka Binder Properties
    37.3.2. Kafka Consumer Properties
    37.3.3. Kafka Producer Properties
    37.3.4. Usage examples
    Example: Setting autoCommitOffset false and relying on manual acking.
    Example: security configuration
    Using the binder with Apache Kafka 0.10
    Excluding Kafka broker jar from the classpath of the binder based application
    37.4. Kafka Streams Binding Capabilities of Spring Cloud Stream
    37.4.1. Usage example of high level streams DSL
    37.4.2. Support for interactive queries
    37.4.3. Kafka Streams properties
    37.5. Error Channels
    37.6. Kafka Metrics
    37.7. Dead-Letter Topic Processing
    38. RabbitMQ Binder
    38.1. Usage
    38.2. RabbitMQ Binder Overview
    38.3. Configuration Options
    38.3.1. RabbitMQ Binder Properties
    38.3.2. RabbitMQ Consumer Properties
    38.3.3. Rabbit Producer Properties
    38.4. Retry With the RabbitMQ Binder
    38.4.1. Overview
    38.4.2. Putting it All Together
    38.5. Error Channels
    38.6. Dead-Letter Queue Processing
    38.6.1. Non-Partitioned Destinations
    38.6.2. Partitioned Destinations
    republishToDlq=false
    republishToDlq=true
    VI. Spring Cloud Bus
    39. Quick Start
    40. Addressing an Instance
    41. Addressing all instances of a service
    42. Application Context ID must be unique
    43. Customizing the Message Broker
    44. Tracing Bus Events
    45. Broadcasting Your Own Events
    45.1. Registering events in custom packages
    VII. Spring Cloud Sleuth
    46. Introduction
    46.1. Terminology
    46.2. Purpose
    46.2.1. Distributed tracing with Zipkin
    46.2.2. Visualizing errors
    46.2.3. Live examples
    46.2.4. Log correlation
    JSON Logback with Logstash
    46.2.5. Propagating Span Context
    Baggage vs. Span Tags
    46.3. Adding to the project
    46.3.1. Only Sleuth (log correlation)
    46.3.2. Sleuth with Zipkin via HTTP
    46.3.3. Sleuth with Zipkin via RabbitMQ or Kafka
    47. Additional resources
    48. Features
    49. Sampling
    50. Instrumentation
    51. Span lifecycle
    51.1. Creating and closing spans
    51.2. Continuing spans
    51.3. Creating spans with an explicit parent
    52. Naming spans
    52.1. @SpanName annotation
    52.2. toString() method
    53. Managing spans with annotations
    53.1. Rationale
    53.2. Creating new spans
    53.3. Continuing spans
    53.4. More advanced tag setting
    53.4.1. Custom extractor
    53.4.2. Resolving expressions for value
    53.4.3. Using toString method
    54. Customizations
    54.1. Spring Integration
    54.2. HTTP
    54.3. Example
    54.4. TraceFilter
    54.5. Custom SA tag in Zipkin
    54.6. Custom service name
    54.7. Customization of reported spans
    54.8. Host locator
    55. Sending spans to Zipkin
    56. Span Data as Messages
    56.1. Zipkin Consumer
    56.2. Custom Consumer
    57. Metrics
    58. Integrations
    58.1. Runnable and Callable
    58.2. Hystrix
    58.2.1. Custom Concurrency Strategy
    58.2.2. Manual Command setting
    58.3. RxJava
    58.4. HTTP integration
    58.4.1. HTTP Filter
    58.4.2. HandlerInterceptor
    58.4.3. Async Servlet support
    58.5. HTTP client integration
    58.5.1. Synchronous Rest Template
    58.5.2. Asynchronous Rest Template
    Multiple Asynchronous Rest Templates
    58.5.3. Traverson
    58.6. Feign
    58.7. Asynchronous communication
    58.7.1. @Async annotated methods
    58.7.2. @Scheduled annotated methods
    58.7.3. Executor, ExecutorService and ScheduledExecutorService
    Customization of Executors
    58.8. Messaging
    58.9. Zuul
    58.10. Spring Cloud Function
    59. Running examples
    VIII. Spring Cloud Consul
    60. Install Consul
    61. Consul Agent
    62. Service Discovery with Consul
    62.1. How to activate
    62.2. Registering with Consul
    62.3. HTTP Health Check
    62.3.1. Metadata and Consul tags
    62.3.2. Making the Consul Instance ID Unique
    62.4. Looking up services
    62.4.1. Using Ribbon
    62.4.2. Using the DiscoveryClient
    63. Distributed Configuration with Consul
    63.1. How to activate
    63.2. Customizing
    63.3. Config Watch
    63.4. YAML or Properties with Config
    63.5. git2consul with Config
    63.6. Fail Fast
    64. Consul Retry
    65. Spring Cloud Bus with Consul
    65.1. How to activate
    66. Circuit Breaker with Hystrix
    67. Hystrix metrics aggregation with Turbine and Consul
    IX. Spring Cloud Zookeeper
    68. Install Zookeeper
    69. Service Discovery with Zookeeper
    69.1. How to activate
    69.2. Registering with Zookeeper
    69.3. Using the DiscoveryClient
    70. Using Spring Cloud Zookeeper with Spring Cloud Netflix Components
    70.1. Ribbon with Zookeeper
    71. Spring Cloud Zookeeper and Service Registry
    71.1. Instance Status
    72. Zookeeper Dependencies
    72.1. Using the Zookeeper Dependencies
    72.2. How to activate Zookeeper Dependencies
    72.3. Setting up Zookeeper Dependencies
    72.3.1. Aliases
    72.3.2. Path
    72.3.3. Load balancer type
    72.3.4. Content-Type template and version
    72.3.5. Default headers
    72.3.6. Obligatory dependencies
    72.3.7. Stubs
    72.4. Configuring Spring Cloud Zookeeper Dependencies
    73. Spring Cloud Zookeeper Dependency Watcher
    73.1. How to activate
    73.2. Registering a listener
    73.3. Presence Checker
    74. Distributed Configuration with Zookeeper
    74.1. How to activate
    74.2. Customizing
    74.3. ACLs
    X. Spring Cloud Security
    75. Quickstart
    75.1. OAuth2 Single Sign On
    75.2. OAuth2 Protected Resource
    76. More Detail
    76.1. Single Sign On
    76.2. Token Relay
    76.2.1. Client Token Relay
    76.2.2. Client Token Relay in Zuul Proxy
    76.2.3. Resource Server Token Relay
    77. Configuring Authentication Downstream of a Zuul Proxy
    XI. Spring Cloud for Cloud Foundry
    78. Discovery
    79. Single Sign On
    XII. Spring Cloud Contract
    80. Spring Cloud Contract
    81. Spring Cloud Contract Verifier Introduction
    81.1. Why a Contract Verifier?
    81.1.1. Testing issues
    81.2. Purposes
    81.3. How It Works
    81.3.1. Defining the contract
    81.3.2. Client Side
    81.3.3. Server Side
    81.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    81.4.1. Technical note
    81.4.2. Consumer side (Loan Issuance)
    81.4.3. Producer side (Fraud Detection server)
    81.4.4. Consumer Side (Loan Issuance) Final Step
    81.5. Dependencies
    81.6. Additional Links
    81.6.1. Spring Cloud Contract video
    81.6.2. Readings
    81.7. Samples
    82. Spring Cloud Contract FAQ
    82.1. Why use Spring Cloud Contract Verifier and not X ?
    82.2. I don’t want to write a contract in Groovy!
    82.3. What is this value(consumer(), producer()) ?
    82.4. How to do Stubs versioning?
    82.4.1. API Versioning
    82.4.2. JAR versioning
    82.4.3. Dev or prod stubs
    82.5. Common repo with contracts
    82.5.1. Repo structure
    82.5.2. Workflow
    82.5.3. Consumer
    82.5.4. Producer
    82.6. Can I have multiple base classes for tests?
    82.7. How can I debug the request/response being sent by the generated tests client?
    82.7.1. How can I debug the mapping/request/response being sent by WireMock?
    82.7.2. How can I see what got registered in the HTTP server stub?
    82.7.3. Can I reference the request from the response?
    82.7.4. Can I reference text from file?
    83. Spring Cloud Contract Verifier Setup
    83.1. Gradle Project
    83.1.1. Prerequisites
    83.1.2. Add Gradle Plugin with Dependencies
    83.1.3. Gradle and Rest Assured 2.0
    83.1.4. Snapshot Versions for Gradle
    83.1.5. Add stubs
    83.1.6. Run the Plugin
    83.1.7. Default Setup
    83.1.8. Configure Plugin
    83.1.9. Configuration Options
    83.1.10. Single Base Class for All Tests
    83.1.11. Different Base Classes for Contracts
    83.1.12. Invoking Generated Tests
    83.1.13. Spring Cloud Contract Verifier on the Consumer Side
    83.2. Maven Project
    83.2.1. Add maven plugin
    83.2.2. Maven and Rest Assured 2.0
    83.2.3. Snapshot versions for Maven
    83.2.4. Add stubs
    83.2.5. Run plugin
    83.2.6. Configure plugin
    83.2.7. Configuration Options
    83.2.8. Single Base Class for All Tests
    83.2.9. Different base classes for contracts
    83.2.10. Invoking generated tests
    83.2.11. Maven Plugin and STS
    83.3. Stubs and Transitive Dependencies
    83.4. CI Server setup
    83.5. Scenarios
    83.6. Docker Project
    83.6.1. Short intro to Maven, JARs and Binary storage
    83.6.2. How it works
    Environment Variables
    83.6.3. Example of usage
    83.6.4. Server side (nodejs)
    84. Spring Cloud Contract Verifier Messaging
    84.1. Integrations
    84.2. Manual Integration Testing
    84.3. Publisher-Side Test Generation
    84.3.1. Scenario 1: No Input Message
    84.3.2. Scenario 2: Output Triggered by Input
    84.3.3. Scenario 3: No Output Message
    84.4. Consumer Stub Generation
    85. Spring Cloud Contract Stub Runner
    85.1. Snapshot versions
    85.2. Publishing Stubs as JARs
    85.3. Stub Runner Core
    85.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    85.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    85.4. Stub Runner JUnit Rule
    85.4.1. Maven settings
    85.4.2. Providing fixed ports
    85.4.3. Fluent API
    85.4.4. Stub Runner with Spring
    85.5. Stub Runner Spring Cloud
    85.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    85.5.2. Additional Configuration
    85.6. Stub Runner Boot Application
    85.6.1. How to use it?
    Stub Runner Server
    Stub Runner Server Fat Jar
    Spring Cloud CLI
    85.6.2. Endpoints
    HTTP
    Messaging
    85.6.3. Example
    85.6.4. Stub Runner Boot with Service Discovery
    85.7. Stubs Per Consumer
    85.8. Common
    85.8.1. Common Properties for JUnit and Spring
    85.8.2. Stub Runner Stubs IDs
    85.9. Stub Runner Docker
    85.9.1. How to use it
    85.9.2. Example of client side usage in a non JVM project
    86. Stub Runner for Messaging
    86.1. Stub triggering
    86.1.1. Trigger by Label
    86.1.2. Trigger by Group and Artifact Ids
    86.1.3. Trigger by Artifact Ids
    86.1.4. Trigger All Messages
    86.2. Stub Runner Camel
    86.2.1. Adding the Runner to the Project
    86.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.3. Stub Runner Integration
    86.3.1. Adding the Runner to the Project
    86.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.4. Stub Runner Stream
    86.4.1. Adding the Runner to the Project
    86.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.5. Stub Runner Spring AMQP
    86.5.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    87. Contract DSL
    87.1. Limitations
    87.2. Common Top-Level elements
    87.2.1. Description
    87.2.2. Name
    87.2.3. Ignoring Contracts
    87.2.4. Passing Values from Files
    87.2.5. HTTP Top-Level Elements
    87.3. Request
    87.4. Response
    87.5. Dynamic properties
    87.5.1. Dynamic properties inside the body
    87.5.2. Regular expressions
    87.5.3. Passing Optional Parameters
    87.5.4. Executing Custom Methods on the Server Side
    87.5.5. Referencing the Request from the Response
    87.5.6. Registering Your Own WireMock Extension
    87.5.7. Dynamic Properties in the Matchers Sections
    87.6. JAX-RS Support
    87.7. Async Support
    87.8. Working with Context Paths
    87.9. Messaging Top-Level Elements
    87.9.1. Output Triggered by a Method
    87.9.2. Output Triggered by a Message
    87.9.3. Consumer/Producer
    87.9.4. Common
    87.10. Multiple Contracts in One File
    88. Customization
    88.1. Extending the DSL
    88.1.1. Common JAR
    88.1.2. Adding the Dependency to the Project
    88.1.3. Test the Dependency in the Project’s Dependencies
    88.1.4. Test a Dependency in the Plugin’s Dependencies
    88.1.5. Referencing classes in DSLs
    89. Using the Pluggable Architecture
    89.1. Custom Contract Converter
    89.1.1. Pact Converter
    89.1.2. Pact Contract
    89.1.3. Pact for Producers
    89.1.4. Pact for Consumers
    89.2. Using the Custom Test Generator
    89.3. Using the Custom Stub Generator
    89.4. Using the Custom Stub Runner
    89.5. Using the Custom Stub Downloader
    90. Spring Cloud Contract WireMock
    90.1. Registering Stubs Automatically
    90.2. Using Files to Specify the Stub Bodies
    90.3. Alternative: Using JUnit Rules
    90.4. Relaxed SSL Validation for Rest Template
    90.5. WireMock and Spring MVC Mocks
    90.6. Customization of WireMock configuration
    90.7. Generating Stubs using REST Docs
    90.8. Generating Contracts by Using REST Docs
    91. Migrations
    91.1. 1.0.x → 1.1.x
    91.1.1. New structure of generated stubs
    91.2. 1.1.x → 1.2.x
    91.2.1. Custom HttpServerStub
    91.2.2. New packages for generated tests
    91.2.3. New Methods in TemplateProcessor
    91.2.4. RestAssured 3.0
    92. Links
    XIII. Spring Cloud Vault
    93. Quick Start
    94. Client Side Usage
    94.1. Authentication
    95. Authentication methods
    95.1. Token authentication
    95.2. AppId authentication
    95.2.1. Custom UserId
    95.3. AppRole authentication
    95.4. AWS-EC2 authentication
    95.5. AWS-IAM authentication
    95.6. TLS certificate authentication
    95.7. Cubbyhole authentication
    95.8. Kubernetes authentication
    96. Secret Backends
    96.1. Generic Backend
    96.2. Consul
    96.3. RabbitMQ
    96.4. AWS
    97. Database backends
    97.1. Apache Cassandra
    97.2. MongoDB
    97.3. MySQL
    97.4. PostgreSQL
    98. Configure PropertySourceLocator behavior
    99. Service Registry Configuration
    100. Vault Client Fail Fast
    101. Vault Client SSL configuration
    102. Lease lifecycle management (renewal and revocation)
    XIV. Appendix: Compendium of Configuration Properties
       Next
       
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault-lease-renewal.html b/Edgware.SR3/multi/multi_vault-lease-renewal.html index 16e37085..65a34e83 100644 --- a/Edgware.SR3/multi/multi_vault-lease-renewal.html +++ b/Edgware.SR3/multi/multi_vault-lease-renewal.html @@ -1,6 +1,6 @@ - 106. Lease lifecycle management (renewal and revocation)
    106. Lease lifecycle management (renewal and revocation)
    Prev Part XIV. Spring Cloud Vault Next

    106. Lease lifecycle management (renewal and revocation)

    With every secret, Vault creates a lease: + 102. Lease lifecycle management (renewal and revocation)

    102. Lease lifecycle management (renewal and revocation)
    Prev Part XIII. Spring Cloud Vault Next

    102. Lease lifecycle management (renewal and revocation)

    With every secret, Vault creates a lease: metadata containing information such as a time duration, renewability, and more.

    Vault promises that the data will be valid for the given duration, or Time To Live (TTL). Once the lease is expired, Vault can @@ -19,4 +19,4 @@ to false. This is not recommended as leases can exp Spring Cloud Vault cannot longer access Vault or services using generated credentials and valid credentials remain active after application shutdown.

    spring.cloud.vault:
-    config.lifecycle.enabled: true

    See also: Vault Documentation: Lease, Renew, and Revoke

    Prev Up Next
    105. Vault Client SSL configuration Home Part XV. Appendix: Compendium of Configuration Properties
    \ No newline at end of file + config.lifecycle.enabled: true

    See also: Vault Documentation: Lease, Renew, and Revoke

    Prev Up Next
    101. Vault Client SSL configuration Home Part XIV. Appendix: Compendium of Configuration Properties
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.authentication.html b/Edgware.SR3/multi/multi_vault.config.authentication.html index cc216fd8..d425432d 100644 --- a/Edgware.SR3/multi/multi_vault.config.authentication.html +++ b/Edgware.SR3/multi/multi_vault.config.authentication.html @@ -1,22 +1,22 @@ - 99. Authentication methods
    99. Authentication methods
    Prev Part XIV. Spring Cloud Vault Next

    99. Authentication methods

    Different organizations have different requirements for security + 95. Authentication methods

    95. Authentication methods
    Prev Part XIII. Spring Cloud Vault Next

    95. Authentication methods

    Different organizations have different requirements for security and authentication. Vault reflects that need by shipping multiple authentication -methods. Spring Cloud Vault supports token and AppId authentication.

    99.1 Token authentication

    Tokens are the core method for authentication within Vault. +methods. Spring Cloud Vault supports token and AppId authentication.

    95.1 Token authentication

    Tokens are the core method for authentication within Vault. Token authentication requires a static token to be provided using the Bootstrap Application Context.

    [Note]Note

    Token authentication is the default authentication method. If a token is disclosed an unintended party gains access to Vault and -can access secrets for the intended client.

    Example 99.1. bootstrap.yml

    spring.cloud.vault:
+can access secrets for the intended client.

    Example 95.1. bootstrap.yml

    spring.cloud.vault:
     authentication: TOKEN
     token: 00000000-0000-0000-0000-000000000000

    • authentication setting this value to TOKEN selects the Token -authentication method
    • token sets the static token to use

    See also: Vault Documentation: Tokens

    99.2 AppId authentication

    Vault supports AppId +authentication method

  • token sets the static token to use

    • See also: Vault Documentation: Tokens

    95.2 AppId authentication

    Vault supports AppId authentication that consists of two hard to guess tokens. The AppId defaults to spring.application.name that is statically configured. The second token is the UserId which is a part determined by the application, usually related to the runtime environment. IP address, Mac address or a Docker container name are good examples. Spring Cloud Vault Config supports IP address, Mac address and static UserId’s (e.g. supplied via System properties). -The IP and Mac address are represented as Hex-encoded SHA256 hash.

    IP address-based UserId’s use the local host’s IP address.

    Example 99.2. bootstrap.yml using SHA256 IP-Address UserId’s

    spring.cloud.vault:
+The IP and Mac address are represented as Hex-encoded SHA256 hash.
    IP address-based UserId’s use the local host’s IP address.
    Example 95.2. bootstrap.yml using SHA256 IP-Address UserId’s
    spring.cloud.vault:
     authentication: APPID
     app-id:
         user-id: IP_ADDRESS

    • authentication setting this value to APPID selects the AppId
@@ -26,42 +26,42 @@ so make sure to include the -n flag.
      <
 localhost-bound device. The configuration also allows specifying
 a network-interface hint to pick the right device. The value of
 network-interface is optional and can be either an interface
-name or interface index (0-based).
      Example 99.3. bootstrap.yml using SHA256 Mac-Address UserId’s
      spring.cloud.vault:
+name or interface index (0-based).
      Example 95.3. bootstrap.yml using SHA256 Mac-Address UserId’s
      spring.cloud.vault:
     authentication: APPID
     app-id:
         user-id: MAC_ADDRESS
         network-interface: eth0

      • network-interface sets network interface to obtain the physical address
      The corresponding command to generate the IP address UserId from a command line is:
      $ echo -n 0AFEDE1234AC | sha256sum
      [Note]Note
      The Mac address is specified uppercase and without colons.
 Including the line break of echo leads to a different hash value
-so make sure to include the -n flag.
      99.2.1 Custom UserId
      The UserId generation is an open mechanism. You can set
+so make sure to include the -n flag.
      95.2.1 Custom UserId
      The UserId generation is an open mechanism. You can set
 spring.cloud.vault.app-id.user-id to any string and the configured
 value will be used as static UserId.
      A more advanced approach lets you set spring.cloud.vault.app-id.user-id to a
 classname. This class must be on your classpath and must implement
 the org.springframework.cloud.vault.AppIdUserIdMechanism interface
 and the createUserId method. Spring Cloud Vault will obtain the UserId
 by calling createUserId each time it authenticates using AppId to
-obtain a token.
      Example 99.4. bootstrap.yml
      spring.cloud.vault:
+obtain a token.
      Example 95.4. bootstrap.yml
      spring.cloud.vault:
     authentication: APPID
     app-id:
-        user-id: com.examlple.MyUserIdMechanism

      Example 99.5. MyUserIdMechanism.java
      public class MyUserIdMechanism implements AppIdUserIdMechanism {
+        user-id: com.examlple.MyUserIdMechanism

      Example 95.5. MyUserIdMechanism.java
      public class MyUserIdMechanism implements AppIdUserIdMechanism {
 
   @Override
   public String createUserId() {
     String userId = ...
     return userId;
   }
-}

      See also: Vault Documentation: Using the App ID auth backend
      99.3 AppRole authentication
      AppRole is intended for machine
-authentication, like the deprecated (since Vault 0.6.1) Section 99.2, “AppId authentication”.
+}

      See also: Vault Documentation: Using the App ID auth backend

    95.3 AppRole authentication

    AppRole is intended for machine +authentication, like the deprecated (since Vault 0.6.1) Section 95.2, “AppId authentication”. AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.

    Spring Vault supports AppRole authentication by providing either RoleId only or together with a provided SecretId (push or pull mode).

    RoleId and optionally SecretId must be provided by configuration, -Spring Vault will not look up these or create a custom SecretId.

    Example 99.6. bootstrap.yml with AppRole authentication properties

    spring.cloud.vault:
+Spring Vault will not look up these or create a custom SecretId.
    Example 95.6. bootstrap.yml with AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
-        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    • role-id sets the RoleId.
    Example 99.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
+        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    • role-id sets the RoleId.
    Example 95.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
         role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
         secret-id: 1696536f-1976-73b1-b241-0b4213908d39
-        app-auth-path: approle

    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
    • approle-path sets the path of the approle authentication mount to use
    See also: Vault Documentation: Using the AppRole auth backend

    99.4 AWS-EC2 authentication

    The aws-ec2 + app-auth-path: approle


    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
    • approle-path sets the path of the approle authentication mount to use

    See also: Vault Documentation: Using the AppRole auth backend

    95.4 AWS-EC2 authentication

    The aws-ec2 auth backend provides a secure introduction mechanism for AWS EC2 instances, allowing automated retrieval of a Vault token. Unlike most Vault authentication backends, this backend @@ -69,7 +69,7 @@ does not require first-deploying, or provisioning security-sensitive credentials (tokens, username/password, client certificates, etc.). Instead, it treats AWS as a Trusted Third Party and uses the cryptographically signed dynamic metadata information that uniquely -represents each EC2 instance.

    Example 99.8. bootstrap.yml using AWS-EC2 Authentication

    spring.cloud.vault:
+represents each EC2 instance.
    Example 95.8. bootstrap.yml using AWS-EC2 Authentication
    spring.cloud.vault:
     authentication: AWS_EC2

    AWS-EC2 authentication enables nonce by default to follow
 the Trust On First Use (TOFU) principle. Any unintended party that
 gains access to the PKCS#7 identity metadata can authenticate
@@ -80,17 +80,17 @@ party does not have the nonce and can raise an alert in Vault for
 further investigation.
    The nonce is kept in memory and is lost during application restart.
 You can configure a static nonce with spring.cloud.vault.aws-ec2.nonce.
    AWS-EC2 authentication roles are optional and default to the AMI.
 You can configure the authentication role by setting the
-spring.cloud.vault.aws-ec2.role property.
    Example 99.9. bootstrap.yml with configured role
    spring.cloud.vault:
+spring.cloud.vault.aws-ec2.role property.
    Example 95.9. bootstrap.yml with configured role
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
-        role: application-server

    Example 99.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
+        role: application-server

    Example 95.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
         role: application-server
         aws-ec2-path: aws-ec2
         identity-document: http://...
         nonce: my-static-nonce

    • authentication setting this value to AWS_EC2 selects the AWS EC2
-authentication method
    • role sets the name of the role against which the login is being attempted.
    • aws-ec2-path sets the path of the AWS EC2 mount to use
    • identity-document sets URL of the PKCS#7 AWS EC2 identity document
    • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    See also: Vault Documentation: Using the aws auth backend
    99.5 AWS-IAM authentication
    The aws backend provides a secure
+authentication method
  • role sets the name of the role against which the login is being attempted.
  • aws-ec2-path sets the path of the AWS EC2 mount to use
  • identity-document sets URL of the PKCS#7 AWS EC2 identity document
  • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    • See also: Vault Documentation: Using the aws auth backend
    95.5 AWS-IAM authentication
    The aws backend provides a secure
 authentication mechanism for AWS IAM roles, allowing the automatic authentication with
 vault based on the current IAM role of the running application.
  Unlike most Vault authentication backends, this backend
@@ -104,36 +104,36 @@ will use the IAM role assigned to the ECS task of the running container.
 If you are running your application naked on top of an EC2 instance then
 the IAM role used will be the one assigned to the EC2 instance.
    When using the AWS-IAM authentication you must create a role in Vault
 and assign it to your IAM role. An empty role defaults to
-the friendly name the current IAM role.
    Example 99.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
-    authentication: AWS_IAM

    Example 99.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
+the friendly name the current IAM role.
    Example 95.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
+    authentication: AWS_IAM

    Example 95.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
     authentication: AWS_IAM
     aws-iam:
         role: my-dev-role
         aws-path: aws
         server-id: some.server.name

    • role sets the name of the role against which the login is being attempted. This should be bound to your IAM role. If one is not supplied then the friendly name of the current IAM user will be used as the vault role.
    • aws-path sets the path of the AWS mount to use
    • server-id sets the value to use for the X-Vault-AWS-IAM-Server-ID header preventing certain types of replay attacks.
    AWS-IAM requires the AWS Java SDK dependency (com.amazonaws:aws-java-sdk-core)
-as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    99.6 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
-certificates that are either signed by a CA or self-signed.
    To enable cert authentication you need to:
    1. Use SSL, see Chapter 105, Vault Client SSL configuration
    2. Configure a Java Keystore that contains the client
-certificate and the private key
    3. Set the spring.cloud.vault.authentication to CERT
    Example 99.13. bootstrap.yml
    spring.cloud.vault:
+as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    95.6 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
+certificates that are either signed by a CA or self-signed.
    To enable cert authentication you need to:
    1. Use SSL, see Chapter 101, Vault Client SSL configuration
    2. Configure a Java Keystore that contains the client
+certificate and the private key
    3. Set the spring.cloud.vault.authentication to CERT
    Example 95.13. bootstrap.yml
    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend
    99.7 Cubbyhole authentication
    Cubbyhole authentication uses Vault primitives to provide a secured authentication
+        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend

    95.7 Cubbyhole authentication

    Cubbyhole authentication uses Vault primitives to provide a secured authentication workflow. Cubbyhole authentication uses tokens as primary login method. An ephemeral token is used to obtain a second, login VaultToken from Vault’s Cubbyhole secret backend. The login token is usually longer-lived and used to interact with Vault. The login token will be retrieved from a wrapped -response stored at /cubbyhole/response.

    Creating a wrapped token

    [Note]Note

    Response Wrapping for token creation requires Vault 0.6.0 or higher.

    Example 99.14. Creating and storing tokens

    $ vault token-create -wrap-ttl="10m"
+response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 95.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
 Key                            Value
 ---                            -----
 wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
 wrapping_token_ttl:            0h10m0s
 wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
-wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 99.15. bootstrap.yml
    spring.cloud.vault:
+wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 95.15. bootstrap.yml
    spring.cloud.vault:
     authentication: CUBBYHOLE
-    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:

    99.8 Kubernetes authentication

    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token. -The authentication is role based and the role is bound to a service account name and a namespace.

    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

    Example 99.16. bootstrap.yml with all Kubernetes authentication properties

    spring.cloud.vault:
+    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:

    95.8 Kubernetes authentication

    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token. +The authentication is role based and the role is bound to a service account name and a namespace.

    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

    Example 95.16. bootstrap.yml with all Kubernetes authentication properties

    spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
-        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

    • role sets the Role.
    • service-account-token-file sets the location of the file containing the Kubernetes Service Account Token. Defaults to /var/run/secrets/kubernetes.io/serviceaccount/token.

    See also:

    Prev Up Next
    98. Client Side Usage Home 100. Secret Backends
    \ No newline at end of file + service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

    • role sets the Role.
    • service-account-token-file sets the location of the file containing the Kubernetes Service Account Token. Defaults to /var/run/secrets/kubernetes.io/serviceaccount/token.

    See also:

    Prev Up Next
    94. Client Side Usage Home 96. Secret Backends
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.backends.configurer.html b/Edgware.SR3/multi/multi_vault.config.backends.configurer.html index 89d08928..937c4afe 100644 --- a/Edgware.SR3/multi/multi_vault.config.backends.configurer.html +++ b/Edgware.SR3/multi/multi_vault.config.backends.configurer.html @@ -1,6 +1,6 @@ - 102. Configure PropertySourceLocator behavior
    102. Configure PropertySourceLocator behavior
    Prev Part XIV. Spring Cloud Vault Next

    102. Configure PropertySourceLocator behavior

    Spring Cloud Vault uses property-based configuration to create PropertySources + 98. Configure PropertySourceLocator behavior

    98. Configure PropertySourceLocator behavior
    Prev Part XIII. Spring Cloud Vault Next

    98. Configure PropertySourceLocator behavior

    Spring Cloud Vault uses property-based configuration to create PropertySources for generic and discovered secret backends.

    Discovered backends provide VaultSecretBackendDescriptor beans to describe the configuration state to use secret backend as PropertySource. A SecretBackendMetadataFactory is required to create a SecretBackendMetadata object which contains path, name and property transformation @@ -19,4 +19,4 @@ at least one VaultConfigurer bean. You can however } }

    [Note]Note

    All customization is required to happen in the bootstrap context. Add your configuration classes to META-INF/spring.factories at org.springframework.cloud.bootstrap.BootstrapConfiguration -in your application.

    Prev Up Next
    101. Database backends Home 103. Service Registry Configuration
    \ No newline at end of file +in your application.

    Prev Up Next
    97. Database backends Home 99. Service Registry Configuration
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.backends.database-backends.html b/Edgware.SR3/multi/multi_vault.config.backends.database-backends.html index e7142bed..ae8f0fca 100644 --- a/Edgware.SR3/multi/multi_vault.config.backends.database-backends.html +++ b/Edgware.SR3/multi/multi_vault.config.backends.database-backends.html @@ -1,23 +1,23 @@ - 101. Database backends
    101. Database backends
    Prev Part XIV. Spring Cloud Vault Next

    101. Database backends

    Vault supports several database secret backends to generate database + 97. Database backends

    97. Database backends
    Prev Part XIII. Spring Cloud Vault Next

    97. Database backends

    Vault supports several database secret backends to generate database credentials dynamically based on configured roles. This means services that need to access a database no longer need to configure credentials: they can request them from Vault, and use Vault’s leasing -mechanism to more easily roll keys.

    Spring Cloud Vault integrates with these backends:

    Using a database secret backend requires to enable the +mechanism to more easily roll keys.

    Spring Cloud Vault integrates with these backends:

    Using a database secret backend requires to enable the backend in the configuration and the spring-cloud-vault-config-databases dependency.

    Vault ships since 0.7.1 with a dedicated database secret backend that allows database integration via plugins. You can use that specific backend by adapting one of the JDBC database properties above. Make sure to specify the appropriate -backend path, e.g. spring.cloud.vault.mysql.role.backend=database.

    Example 101.1. pom.xml

    <dependencies>
+backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 97.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-databases</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    [Note]Note
    Enabling multiple JDBC-compliant databases will generate credentials
 and store them by default in the same property keys hence property names for
-JDBC secrets need to be configured separately.
    101.1 Apache Cassandra
    Spring Cloud Vault can obtain credentials for Apache Cassandra.
+JDBC secrets need to be configured separately.
    97.1 Apache Cassandra
    Spring Cloud Vault can obtain credentials for Apache Cassandra.
 The integration can be enabled by setting
 spring.cloud.vault.cassandra.enabled=true (default false) and
 providing the role name with spring.cloud.vault.cassandra.role=….
    Username and password are stored in spring.data.cassandra.username
@@ -31,7 +31,7 @@ You can configure the property names by setting
         role: readonly
         backend: cassandra
         username-property: spring.data.cassandra.username
-        password-property: spring.data.cassandra.username
    • enabled setting this value to true enables the Cassandra backend config usage
    • role sets the role name of the Cassandra role definition
    • backend sets the path of the Cassandra mount to use
    • username-property sets the property name in which the Cassandra username is stored
    • password-property sets the property name in which the Cassandra password is stored

    See also: Vault Documentation: Setting up Apache Cassandra with Vault

    101.2 MongoDB

    Spring Cloud Vault can obtain credentials for MongoDB. + password-property: spring.data.cassandra.username

    • enabled setting this value to true enables the Cassandra backend config usage
    • role sets the role name of the Cassandra role definition
    • backend sets the path of the Cassandra mount to use
    • username-property sets the property name in which the Cassandra username is stored
    • password-property sets the property name in which the Cassandra password is stored

    See also: Vault Documentation: Setting up Apache Cassandra with Vault

    97.2 MongoDB

    Spring Cloud Vault can obtain credentials for MongoDB. The integration can be enabled by setting spring.cloud.vault.mongodb.enabled=true (default false) and providing the role name with spring.cloud.vault.mongodb.role=….

    Username and password are stored in spring.data.mongodb.username @@ -45,7 +45,7 @@ You can configure the property names by setting role: readonly backend: mongodb username-property: spring.data.mongodb.username - password-property: spring.data.mongodb.password

    • enabled setting this value to true enables the MongodB backend config usage
    • role sets the role name of the MongoDB role definition
    • backend sets the path of the MongoDB mount to use
    • username-property sets the property name in which the MongoDB username is stored
    • password-property sets the property name in which the MongoDB password is stored

    See also: Vault Documentation: Setting up MongoDB with Vault

    101.3 MySQL

    Spring Cloud Vault can obtain credentials for MySQL. + password-property: spring.data.mongodb.password

    • enabled setting this value to true enables the MongodB backend config usage
    • role sets the role name of the MongoDB role definition
    • backend sets the path of the MongoDB mount to use
    • username-property sets the property name in which the MongoDB username is stored
    • password-property sets the property name in which the MongoDB password is stored

    See also: Vault Documentation: Setting up MongoDB with Vault

    97.3 MySQL

    Spring Cloud Vault can obtain credentials for MySQL. The integration can be enabled by setting spring.cloud.vault.mysql.enabled=true (default false) and providing the role name with spring.cloud.vault.mysql.role=….

    Username and password are stored in spring.datasource.username @@ -59,7 +59,7 @@ You can configure the property names by setting role: readonly backend: mysql username-property: spring.datasource.username - password-property: spring.datasource.username

    • enabled setting this value to true enables the MySQL backend config usage
    • role sets the role name of the MySQL role definition
    • backend sets the path of the MySQL mount to use
    • username-property sets the property name in which the MySQL username is stored
    • password-property sets the property name in which the MySQL password is stored

    See also: Vault Documentation: Setting up MySQL with Vault

    101.4 PostgreSQL

    Spring Cloud Vault can obtain credentials for PostgreSQL. + password-property: spring.datasource.username

    • enabled setting this value to true enables the MySQL backend config usage
    • role sets the role name of the MySQL role definition
    • backend sets the path of the MySQL mount to use
    • username-property sets the property name in which the MySQL username is stored
    • password-property sets the property name in which the MySQL password is stored

    See also: Vault Documentation: Setting up MySQL with Vault

    97.4 PostgreSQL

    Spring Cloud Vault can obtain credentials for PostgreSQL. The integration can be enabled by setting spring.cloud.vault.postgresql.enabled=true (default false) and providing the role name with spring.cloud.vault.postgresql.role=….

    Username and password are stored in spring.datasource.username @@ -73,4 +73,4 @@ You can configure the property names by setting role: readonly backend: postgresql username-property: spring.datasource.username - password-property: spring.datasource.username

    • enabled setting this value to true enables the PostgreSQL backend config usage
    • role sets the role name of the PostgreSQL role definition
    • backend sets the path of the PostgreSQL mount to use
    • username-property sets the property name in which the PostgreSQL username is stored
    • password-property sets the property name in which the PostgreSQL password is stored

    See also: Vault Documentation: Setting up PostgreSQL with Vault

    Prev Up Next
    100. Secret Backends Home 102. Configure PropertySourceLocator behavior
    \ No newline at end of file + password-property: spring.datasource.username
    • enabled setting this value to true enables the PostgreSQL backend config usage
    • role sets the role name of the PostgreSQL role definition
    • backend sets the path of the PostgreSQL mount to use
    • username-property sets the property name in which the PostgreSQL username is stored
    • password-property sets the property name in which the PostgreSQL password is stored

    See also: Vault Documentation: Setting up PostgreSQL with Vault

    Prev Up Next
    96. Secret Backends Home 98. Configure PropertySourceLocator behavior
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.backends.html b/Edgware.SR3/multi/multi_vault.config.backends.html index d8b7fae6..842b685e 100644 --- a/Edgware.SR3/multi/multi_vault.config.backends.html +++ b/Edgware.SR3/multi/multi_vault.config.backends.html @@ -1,6 +1,6 @@ - 100. Secret Backends
    100. Secret Backends
    Prev Part XIV. Spring Cloud Vault Next

    100. Secret Backends

    100.1 Generic Backend

    Spring Cloud Vault supports at the basic level the generic secret + 96. Secret Backends

    96. Secret Backends
    Prev Part XIII. Spring Cloud Vault Next

    96. Secret Backends

    96.1 Generic Backend

    Spring Cloud Vault supports at the basic level the generic secret backend. The generic secret backend allows storage of arbitrary values as key-value store. A single context can store one or many key-value tuples. Contexts can be organized hierarchically. @@ -20,13 +20,13 @@ No active profiles will skip accessing contexts with a profile name.

    Prope default-context: application application-name: my-app

    • enabled setting this value to false disables the secret backend config usage
    • backend sets the path of the secret mount to use
    • default-context sets the context name used by all applications
    • application-name overrides the application name for use in the generic backend
    • profile-separator separates the profile name from the context in -property sources with profiles

    See also: Vault Documentation: Using the generic secret backend

    100.2 Consul

    Spring Cloud Vault can obtain credentials for HashiCorp Consul. +property sources with profiles

    See also: Vault Documentation: Using the generic secret backend

    96.2 Consul

    Spring Cloud Vault can obtain credentials for HashiCorp Consul. The Consul integration requires the spring-cloud-vault-config-consul -dependency.

    Example 100.1. pom.xml

    <dependencies>
+dependency.
    Example 96.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -38,12 +38,12 @@ the property name by setting spring.cloud.vault.consul.tok
         enabled: true
         role: readonly
         backend: consul
-        token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored

    See also: Vault Documentation: Setting up Consul with Vault

    100.3 RabbitMQ

    Spring Cloud Vault can obtain credentials for RabbitMQ.

    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq -dependency.

    Example 100.2. pom.xml

    <dependencies>
+        token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored

    See also: Vault Documentation: Setting up Consul with Vault

    96.3 RabbitMQ

    Spring Cloud Vault can obtain credentials for RabbitMQ.

    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq +dependency.

    Example 96.2. pom.xml

    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting spring.cloud.vault.rabbitmq.enabled=true (default false) @@ -57,12 +57,12 @@ by setting spring.cloud.vault.rabbitmq.username-property role: readonly backend: rabbitmq username-property: spring.rabbitmq.username - password-property: spring.rabbitmq.password

    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored

    See also: Vault Documentation: Setting up RabbitMQ with Vault

    100.4 AWS

    Spring Cloud Vault can obtain credentials for AWS.

    The AWS integration requires the spring-cloud-vault-config-aws -dependency.

    Example 100.3. pom.xml

    <dependencies>
+        password-property: spring.rabbitmq.password
    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored

    See also: Vault Documentation: Setting up RabbitMQ with Vault

    96.4 AWS

    Spring Cloud Vault can obtain credentials for AWS.

    The AWS integration requires the spring-cloud-vault-config-aws +dependency.

    Example 96.3. pom.xml

    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting spring.cloud.vault.aws=true (default false) @@ -76,4 +76,4 @@ by setting spring.cloud.vault.aws.access-key-property role: readonly backend: aws access-key-property: cloud.aws.credentials.accessKey - secret-key-property: cloud.aws.credentials.secretKey

    • enabled setting this value to true enables the AWS backend config usage
    • role sets the role name of the AWS role definition
    • backend sets the path of the AWS mount to use
    • access-key-property sets the property name in which the AWS access key is stored
    • secret-key-property sets the property name in which the AWS secret key is stored

    See also: Vault Documentation: Setting up AWS with Vault

    Prev Up Next
    99. Authentication methods Home 101. Database backends
    \ No newline at end of file + secret-key-property: cloud.aws.credentials.secretKey
    • enabled setting this value to true enables the AWS backend config usage
    • role sets the role name of the AWS role definition
    • backend sets the path of the AWS mount to use
    • access-key-property sets the property name in which the AWS access key is stored
    • secret-key-property sets the property name in which the AWS secret key is stored

    See also: Vault Documentation: Setting up AWS with Vault

    Prev Up Next
    95. Authentication methods Home 97. Database backends
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.fail-fast.html b/Edgware.SR3/multi/multi_vault.config.fail-fast.html index 314a8b54..d4efd6d5 100644 --- a/Edgware.SR3/multi/multi_vault.config.fail-fast.html +++ b/Edgware.SR3/multi/multi_vault.config.fail-fast.html @@ -1,8 +1,8 @@ - 104. Vault Client Fail Fast
    104. Vault Client Fail Fast
    Prev Part XIV. Spring Cloud Vault Next

    104. Vault Client Fail Fast

    In some cases, it may be desirable to fail startup of a service if + 100. Vault Client Fail Fast

    100. Vault Client Fail Fast
    Prev Part XIII. Spring Cloud Vault Next

    100. Vault Client Fail Fast

    In some cases, it may be desirable to fail startup of a service if it cannot connect to the Vault Server. If this is the desired behavior, set the bootstrap configuration property spring.cloud.vault.fail-fast=true and the client will halt with an Exception.

    spring.cloud.vault:
-    fail-fast: true
    Prev Up Next
    103. Service Registry Configuration Home 105. Vault Client SSL configuration
    \ No newline at end of file + fail-fast: true
    Prev Up Next
    99. Service Registry Configuration Home 101. Vault Client SSL configuration
    \ No newline at end of file diff --git a/Edgware.SR3/multi/multi_vault.config.ssl.html b/Edgware.SR3/multi/multi_vault.config.ssl.html index fed165a4..06b42a23 100644 --- a/Edgware.SR3/multi/multi_vault.config.ssl.html +++ b/Edgware.SR3/multi/multi_vault.config.ssl.html @@ -1,6 +1,6 @@ - 105. Vault Client SSL configuration
    105. Vault Client SSL configuration
    Prev Part XIV. Spring Cloud Vault Next

    105. Vault Client SSL configuration

    SSL can be configured declaratively by setting various properties. + 101. Vault Client SSL configuration

    101. Vault Client SSL configuration
    Prev Part XIII. Spring Cloud Vault Next

    101. Vault Client SSL configuration

    SSL can be configured declaratively by setting various properties. You can set either javax.net.ssl.trustStore to configure JVM-wide SSL settings or spring.cloud.vault.ssl.trust-store to set SSL settings only for Spring Cloud Vault Config.

    spring.cloud.vault:
@@ -10,4 +10,4 @@ to set SSL settings only for Spring Cloud Vault Config.
    trust-store-password sets the trust-store password
    Please note that configuring spring.cloud.vault.ssl.* can be only
 applied when either Apache Http Components or the OkHttp client
-is on your class-path.
    Prev Up Next
    104. Vault Client Fail Fast Home 106. Lease lifecycle management (renewal and revocation)
    \ No newline at end of file +is on your class-path.

    Prev Up Next
    100. Vault Client Fail Fast Home 102. Lease lifecycle management (renewal and revocation)
    \ No newline at end of file diff --git a/Edgware.SR3/single/images/sts_exception.png b/Edgware.SR3/single/images/sts_exception.png new file mode 100644 index 00000000..8607c38a Binary files /dev/null and b/Edgware.SR3/single/images/sts_exception.png differ diff --git a/Edgware.SR3/single/images/web-selected.png b/Edgware.SR3/single/images/web-selected.png new file mode 100644 index 00000000..aa6b2da6 Binary files /dev/null and b/Edgware.SR3/single/images/web-selected.png differ diff --git a/Edgware.SR3/single/spring-cloud.html b/Edgware.SR3/single/spring-cloud.html index be39bab1..5ac78d93 100644 --- a/Edgware.SR3/single/spring-cloud.html +++ b/Edgware.SR3/single/spring-cloud.html @@ -1,6 +1,6 @@ - Spring Cloud

    Spring Cloud

    Table of Contents

    1. Features
    I. Cloud Native Applications
    2. Spring Cloud Context: Application Context Services
    2.1. The Bootstrap Application Context
    2.2. Application Context Hierarchies
    2.3. Changing the Location of Bootstrap Properties
    2.4. Overriding the Values of Remote Properties
    2.5. Customizing the Bootstrap Configuration
    2.6. Customizing the Bootstrap Property Sources
    2.7. Environment Changes
    2.8. Refresh Scope
    2.9. Encryption and Decryption
    2.10. Endpoints
    3. Spring Cloud Commons: Common Abstractions
    3.1. @EnableDiscoveryClient
    3.1.1. Health Indicator
    3.2. ServiceRegistry
    3.2.1. ServiceRegistry Auto-Registration
    3.2.2. Service Registry Actuator Endpoint
    3.3. Spring RestTemplate as a Load Balancer Client
    3.3.1. Retrying Failed Requests
    3.4. Multiple RestTemplate objects
    3.5. Ignore Network Interfaces
    3.6. HTTP Client Factories
    II. Spring Cloud Config
    4. Quick Start
    4.1. Client Side Usage
    5. Spring Cloud Config Server
    5.1. Environment Repository
    5.1.1. Git Backend
    Placeholders in Git URI
    Pattern Matching and Multiple Repositories
    Authentication
    Authentication with AWS CodeCommit
    Git SSH configuration using properties
    Placeholders in Git Search Paths
    Force pull in Git Repositories
    Deleting untracked branches in Git Repositories
    5.1.2. Version Control Backend Filesystem Use
    5.1.3. File System Backend
    5.1.4. Vault Backend
    Multiple Properties Sources
    5.1.5. Sharing Configuration With All Applications
    File Based Repositories
    Vault Server
    5.1.6. JDBC Backend
    5.1.7. Composite Environment Repositories
    Custom Composite Environment Repositories
    5.1.8. Property Overrides
    5.2. Health Indicator
    5.3. Security
    5.4. Encryption and Decryption
    5.5. Key Management
    5.6. Creating a Key Store for Testing
    5.7. Using Multiple Keys and Key Rotation
    5.8. Serving Encrypted Properties
    6. Serving Alternative Formats
    7. Serving Plain Text
    8. Embedding the Config Server
    9. Push Notifications and Spring Cloud Bus
    10. Spring Cloud Config Client
    10.1. Config First Bootstrap
    10.2. Discovery First Bootstrap
    10.3. Config Client Fail Fast
    10.4. Config Client Retry
    10.5. Locating Remote Configuration Resources
    10.6. Security
    10.6.1. Health Indicator
    10.6.2. Providing A Custom RestTemplate
    10.6.3. Vault
    10.7. Vault
    10.7.1. Nested Keys In Vault
    III. Spring Cloud Netflix
    11. Service Discovery: Eureka Clients
    11.1. How to Include Eureka Client
    11.2. Registering with Eureka
    11.3. Authenticating with the Eureka Server
    11.4. Status Page and Health Indicator
    11.5. Registering a Secure Application
    11.6. Eureka’s Health Checks
    11.7. Eureka Metadata for Instances and Clients
    11.7.1. Using Eureka on Cloudfoundry
    11.7.2. Using Eureka on AWS
    11.7.3. Changing the Eureka Instance ID
    11.8. Using the EurekaClient
    11.8.1. EurekaClient without Jersey
    11.9. Alternatives to the native Netflix EurekaClient
    11.10. Why is it so Slow to Register a Service?
    11.11. Zones
    12. Service Discovery: Eureka Server
    12.1. How to Include Eureka Server
    12.2. How to Run a Eureka Server
    12.3. High Availability, Zones and Regions
    12.4. Standalone Mode
    12.5. Peer Awareness
    12.6. Prefer IP Address
    13. Circuit Breaker: Hystrix Clients
    13.1. How to Include Hystrix
    13.2. Propagating the Security Context or using Spring Scopes
    13.3. Health Indicator
    13.4. Hystrix Metrics Stream
    14. Circuit Breaker: Hystrix Dashboard
    15. Hystrix Timeouts And Ribbon Clients
    15.1. How to Include Hystrix Dashboard
    15.2. Turbine
    15.3. Turbine Stream
    16. Client Side Load Balancer: Ribbon
    16.1. How to Include Ribbon
    16.2. Customizing the Ribbon Client
    16.3. Customizing default for all Ribbon Clients
    16.4. Customizing the Ribbon Client using properties
    16.5. Using Ribbon with Eureka
    16.6. Example: How to Use Ribbon Without Eureka
    16.7. Example: Disable Eureka use in Ribbon
    16.8. Using the Ribbon API Directly
    16.9. Caching of Ribbon Configuration
    16.10. How to Configure Hystrix thread pools
    16.11. How to Provide a Key to Ribbon’s IRule
    17. Declarative REST Client: Feign
    17.1. How to Include Feign
    17.2. Overriding Feign Defaults
    17.3. Creating Feign Clients Manually
    17.4. Feign Hystrix Support
    17.5. Feign Hystrix Fallbacks
    17.6. Feign and @Primary
    17.7. Feign Inheritance Support
    17.8. Feign request/response compression
    17.9. Feign logging
    18. External Configuration: Archaius
    19. Router and Filter: Zuul
    19.1. How to Include Zuul
    19.2. Embedded Zuul Reverse Proxy
    19.3. Zuul Http Client
    19.4. Cookies and Sensitive Headers
    19.5. Ignored Headers
    19.6. Management Endpoints
    19.6.1. Routes Endpoint
    19.6.2. Filters Endpoint
    19.7. Strangulation Patterns and Local Forwards
    19.8. Uploading Files through Zuul
    19.9. Query String Encoding
    19.10. Plain Embedded Zuul
    19.11. Disable Zuul Filters
    19.12. Providing Hystrix Fallbacks For Routes
    19.13. Zuul Timeouts
    19.13.1. Service Discovery Configuration
    19.13.2. URL Configuration
    19.14. Rewriting Location header
    19.15. Zuul Developer Guide
    19.15.1. The Zuul Servlet
    19.15.2. Zuul RequestContext
    19.15.3. @EnableZuulProxy vs. @EnableZuulServer
    19.15.4. @EnableZuulServer Filters
    19.15.5. @EnableZuulProxy Filters
    19.15.6. Custom Zuul Filter examples
    19.15.7. How to Write a Pre Filter
    19.15.8. How to Write a Route Filter
    19.15.9. How to Write a Post Filter
    19.15.10. How Zuul Errors Work
    19.15.11. Zuul Eager Application Context Loading
    20. Polyglot support with Sidecar
    21. RxJava with Spring MVC
    22. Metrics: Spectator, Servo, and Atlas
    22.1. Dimensional vs. Hierarchical Metrics
    22.2. Default Metrics Collection
    22.3. Metrics Collection: Spectator
    22.3.1. Spectator Counter
    22.3.2. Spectator Timer
    22.3.3. Spectator Gauge
    22.3.4. Spectator Distribution Summaries
    22.4. Metrics Collection: Servo
    22.4.1. Creating Servo Monitors
    22.5. Metrics Backend: Atlas
    22.5.1. Global tags
    22.5.2. Using Atlas
    22.6. Retrying Failed Requests
    22.6.1. BackOff Policies
    22.6.2. Configuration
    22.6.3. Zuul
    23. HTTP Clients
    IV. Spring Cloud Stream
    24. Introducing Spring Cloud Stream
    25. Main Concepts
    25.1. Application Model
    25.1.1. Fat JAR
    25.2. The Binder Abstraction
    25.3. Persistent Publish-Subscribe Support
    25.4. Consumer Groups
    25.4.1. Durability
    25.5. Partitioning Support
    26. Programming Model
    26.1. Declaring and Binding Channels
    26.1.1. Triggering Binding Via @EnableBinding
    26.1.2. @Input and @Output
    Customizing Channel Names
    Source, Sink, and Processor
    26.1.3. Accessing Bound Channels
    Injecting the Bound Interfaces
    Injecting Channels Directly
    26.1.4. Producing and Consuming Messages
    Native Spring Integration Support
    Spring Integration Error Channel Support
    Message Channel Binders and Error Channels
    Using @StreamListener for Automatic Content Type Handling
    Using @StreamListener for dispatching messages to multiple methods
    26.1.5. Reactive Programming Support
    Reactor-based handlers
    RxJava 1.x support
    Reactive Sources
    26.1.6. Aggregation
    Configuring aggregate application
    Configuring binding service properties for non self contained aggregate application
    27. Binders
    27.1. Producers and Consumers
    27.2. Binder SPI
    27.3. Binder Detection
    27.3.1. Classpath Detection
    27.4. Multiple Binders on the Classpath
    27.5. Connecting to Multiple Systems
    27.6. Binder configuration properties
    28. Configuration Options
    28.1. Spring Cloud Stream Properties
    28.2. Binding Properties
    28.2.1. Properties for Use of Spring Cloud Stream
    28.2.2. Consumer properties
    28.2.3. Producer Properties
    28.3. Using dynamically bound destinations
    29. Content Type and Transformation
    29.1. MIME types
    29.2. MIME types and Java types
    29.3. Customizing message conversion
    29.4. @StreamListener and Message Conversion
    30. Schema evolution support
    30.1. Apache Avro Message Converters
    30.2. Converters with schema support
    30.3. Schema Registry Support
    30.4. Schema Registry Server
    30.4.1. Schema Registry Server API
    POST /
    GET /{subject}/{format}/{version}
    GET /{subject}/{format}
    GET /schemas/{id}
    DELETE /{subject}/{format}/{version}
    DELETE /schemas/{id}
    DELETE /{subject}
    30.5. Schema Registry Client
    30.5.1. Using Confluent’s Schema Registry
    30.5.2. Schema Registry Client properties
    30.6. Avro Schema Registry Client Message Converters
    30.6.1. Avro Schema Registry Message Converter properties
    30.7. Schema Registration and Resolution
    30.7.1. Schema Registration Process (Serialization)
    30.7.2. Schema Resolution Process (Deserialization)
    31. Inter-Application Communication
    31.1. Connecting Multiple Application Instances
    31.2. Instance Index and Instance Count
    31.3. Partitioning
    31.3.1. Configuring Output Bindings for Partitioning
    Spring-managed custom PartitionKeyExtractorClass implementations
    Configuring Input Bindings for Partitioning
    32. Testing
    32.1. Disabling the test binder autoconfiguration
    33. Health Indicator
    34. Metrics Emitter
    35. Samples
    36. Getting Started
    36.1. Deploying Stream applications on CloudFoundry
    V. Binder Implementations
    37. Apache Kafka Binder
    37.1. Usage
    37.2. Apache Kafka Binder Overview
    37.3. Configuration Options
    37.3.1. Kafka Binder Properties
    37.3.2. Kafka Consumer Properties
    37.3.3. Kafka Producer Properties
    37.3.4. Usage examples
    Example: Setting autoCommitOffset false and relying on manual acking.
    Example: security configuration
    Using the binder with Apache Kafka 0.10
    Excluding Kafka broker jar from the classpath of the binder based application
    37.4. Kafka Streams Binding Capabilities of Spring Cloud Stream
    37.4.1. Usage example of high level streams DSL
    37.4.2. Support for interactive queries
    37.4.3. Kafka Streams properties
    37.5. Error Channels
    37.6. Kafka Metrics
    37.7. Dead-Letter Topic Processing
    38. RabbitMQ Binder
    38.1. Usage
    38.2. RabbitMQ Binder Overview
    38.3. Configuration Options
    38.3.1. RabbitMQ Binder Properties
    38.3.2. RabbitMQ Consumer Properties
    38.3.3. Rabbit Producer Properties
    38.4. Retry With the RabbitMQ Binder
    38.4.1. Overview
    38.4.2. Putting it All Together
    38.5. Error Channels
    38.6. Dead-Letter Queue Processing
    38.6.1. Non-Partitioned Destinations
    38.6.2. Partitioned Destinations
    republishToDlq=false
    republishToDlq=true
    VI. Spring Cloud Bus
    39. Quick Start
    40. Addressing an Instance
    41. Addressing all instances of a service
    42. Application Context ID must be unique
    43. Customizing the Message Broker
    44. Tracing Bus Events
    45. Broadcasting Your Own Events
    45.1. Registering events in custom packages
    VII. Spring Cloud Sleuth
    46. Introduction
    46.1. Terminology
    46.2. Purpose
    46.2.1. Distributed tracing with Zipkin
    46.2.2. Visualizing errors
    46.2.3. Live examples
    46.2.4. Log correlation
    JSON Logback with Logstash
    46.2.5. Propagating Span Context
    Baggage vs. Span Tags
    46.3. Adding to the project
    46.3.1. Only Sleuth (log correlation)
    46.3.2. Sleuth with Zipkin via HTTP
    46.3.3. Sleuth with Zipkin via RabbitMQ or Kafka
    47. Additional resources
    48. Features
    49. Sampling
    50. Instrumentation
    51. Span lifecycle
    51.1. Creating and closing spans
    51.2. Continuing spans
    51.3. Creating spans with an explicit parent
    52. Naming spans
    52.1. @SpanName annotation
    52.2. toString() method
    53. Managing spans with annotations
    53.1. Rationale
    53.2. Creating new spans
    53.3. Continuing spans
    53.4. More advanced tag setting
    53.4.1. Custom extractor
    53.4.2. Resolving expressions for value
    53.4.3. Using toString method
    54. Customizations
    54.1. Spring Integration
    54.2. HTTP
    54.3. Example
    54.4. TraceFilter
    54.5. Custom SA tag in Zipkin
    54.6. Custom service name
    54.7. Customization of reported spans
    54.8. Host locator
    55. Sending spans to Zipkin
    56. Span Data as Messages
    56.1. Zipkin Consumer
    56.2. Custom Consumer
    57. Metrics
    58. Integrations
    58.1. Runnable and Callable
    58.2. Hystrix
    58.2.1. Custom Concurrency Strategy
    58.2.2. Manual Command setting
    58.3. RxJava
    58.4. HTTP integration
    58.4.1. HTTP Filter
    58.4.2. HandlerInterceptor
    58.4.3. Async Servlet support
    58.5. HTTP client integration
    58.5.1. Synchronous Rest Template
    58.5.2. Asynchronous Rest Template
    Multiple Asynchronous Rest Templates
    58.5.3. Traverson
    58.6. Feign
    58.7. Asynchronous communication
    58.7.1. @Async annotated methods
    58.7.2. @Scheduled annotated methods
    58.7.3. Executor, ExecutorService and ScheduledExecutorService
    Customization of Executors
    58.8. Messaging
    58.9. Zuul
    58.10. Spring Cloud Function
    59. Running examples
    VIII. Spring Cloud Consul
    60. Install Consul
    61. Consul Agent
    62. Service Discovery with Consul
    62.1. How to activate
    62.2. Registering with Consul
    62.3. HTTP Health Check
    62.3.1. Metadata and Consul tags
    62.3.2. Making the Consul Instance ID Unique
    62.4. Looking up services
    62.4.1. Using Ribbon
    62.4.2. Using the DiscoveryClient
    63. Distributed Configuration with Consul
    63.1. How to activate
    63.2. Customizing
    63.3. Config Watch
    63.4. YAML or Properties with Config
    63.5. git2consul with Config
    63.6. Fail Fast
    64. Consul Retry
    65. Spring Cloud Bus with Consul
    65.1. How to activate
    66. Circuit Breaker with Hystrix
    67. Hystrix metrics aggregation with Turbine and Consul
    IX. Spring Cloud Zookeeper
    68. Install Zookeeper
    69. Service Discovery with Zookeeper
    69.1. How to activate
    69.2. Registering with Zookeeper
    69.3. Using the DiscoveryClient
    70. Using Spring Cloud Zookeeper with Spring Cloud Netflix Components
    70.1. Ribbon with Zookeeper
    71. Spring Cloud Zookeeper and Service Registry
    71.1. Instance Status
    72. Zookeeper Dependencies
    72.1. Using the Zookeeper Dependencies
    72.2. How to activate Zookeeper Dependencies
    72.3. Setting up Zookeeper Dependencies
    72.3.1. Aliases
    72.3.2. Path
    72.3.3. Load balancer type
    72.3.4. Content-Type template and version
    72.3.5. Default headers
    72.3.6. Obligatory dependencies
    72.3.7. Stubs
    72.4. Configuring Spring Cloud Zookeeper Dependencies
    73. Spring Cloud Zookeeper Dependency Watcher
    73.1. How to activate
    73.2. Registering a listener
    73.3. Presence Checker
    74. Distributed Configuration with Zookeeper
    74.1. How to activate
    74.2. Customizing
    74.3. ACLs
    X. Spring Boot Cloud CLI
    75. Installation
    76. Running Spring Cloud Services in Development
    76.1. Adding Additional Applications
    77. Writing Groovy Scripts and Running Applications
    78. Encryption and Decryption
    XI. Spring Cloud Security
    79. Quickstart
    79.1. OAuth2 Single Sign On
    79.2. OAuth2 Protected Resource
    80. More Detail
    80.1. Single Sign On
    80.2. Token Relay
    80.2.1. Client Token Relay
    80.2.2. Client Token Relay in Zuul Proxy
    80.2.3. Resource Server Token Relay
    81. Configuring Authentication Downstream of a Zuul Proxy
    XII. Spring Cloud for Cloud Foundry
    82. Discovery
    83. Single Sign On
    XIII. Spring Cloud Contract
    84. Spring Cloud Contract
    85. Spring Cloud Contract Verifier Introduction
    85.1. Why a Contract Verifier?
    85.1.1. Testing issues
    85.2. Purposes
    85.3. How It Works
    85.3.1. Defining the contract
    85.3.2. Client Side
    85.3.3. Server Side
    85.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    85.4.1. Technical note
    85.4.2. Consumer side (Loan Issuance)
    85.4.3. Producer side (Fraud Detection server)
    85.4.4. Consumer Side (Loan Issuance) Final Step
    85.5. Dependencies
    85.6. Additional Links
    85.6.1. Spring Cloud Contract video
    85.6.2. Readings
    85.7. Samples
    86. Spring Cloud Contract FAQ
    86.1. Why use Spring Cloud Contract Verifier and not X ?
    86.2. I don’t want to write a contract in Groovy!
    86.3. What is this value(consumer(), producer()) ?
    86.4. How to do Stubs versioning?
    86.4.1. API Versioning
    86.4.2. JAR versioning
    86.4.3. Dev or prod stubs
    86.5. Common repo with contracts
    86.5.1. Repo structure
    86.5.2. Workflow
    86.5.3. Consumer
    86.5.4. Producer
    86.6. Can I have multiple base classes for tests?
    86.7. How can I debug the request/response being sent by the generated tests client?
    86.7.1. How can I debug the mapping/request/response being sent by WireMock?
    86.7.2. How can I see what got registered in the HTTP server stub?
    86.7.3. Can I reference the request from the response?
    86.7.4. Can I reference text from file?
    87. Spring Cloud Contract Verifier Setup
    87.1. Gradle Project
    87.1.1. Prerequisites
    87.1.2. Add Gradle Plugin with Dependencies
    87.1.3. Gradle and Rest Assured 2.0
    87.1.4. Snapshot Versions for Gradle
    87.1.5. Add stubs
    87.1.6. Run the Plugin
    87.1.7. Default Setup
    87.1.8. Configure Plugin
    87.1.9. Configuration Options
    87.1.10. Single Base Class for All Tests
    87.1.11. Different Base Classes for Contracts
    87.1.12. Invoking Generated Tests
    87.1.13. Spring Cloud Contract Verifier on the Consumer Side
    87.2. Maven Project
    87.2.1. Add maven plugin
    87.2.2. Maven and Rest Assured 2.0
    87.2.3. Snapshot versions for Maven
    87.2.4. Add stubs
    87.2.5. Run plugin
    87.2.6. Configure plugin
    87.2.7. Configuration Options
    87.2.8. Single Base Class for All Tests
    87.2.9. Different base classes for contracts
    87.2.10. Invoking generated tests
    87.2.11. Maven Plugin and STS
    87.3. Stubs and Transitive Dependencies
    87.4. CI Server setup
    87.5. Scenarios
    87.6. Docker Project
    87.6.1. Short intro to Maven, JARs and Binary storage
    87.6.2. How it works
    Environment Variables
    87.6.3. Example of usage
    87.6.4. Server side (nodejs)
    88. Spring Cloud Contract Verifier Messaging
    88.1. Integrations
    88.2. Manual Integration Testing
    88.3. Publisher-Side Test Generation
    88.3.1. Scenario 1: No Input Message
    88.3.2. Scenario 2: Output Triggered by Input
    88.3.3. Scenario 3: No Output Message
    88.4. Consumer Stub Generation
    89. Spring Cloud Contract Stub Runner
    89.1. Snapshot versions
    89.2. Publishing Stubs as JARs
    89.3. Stub Runner Core
    89.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    89.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    89.4. Stub Runner JUnit Rule
    89.4.1. Maven settings
    89.4.2. Providing fixed ports
    89.4.3. Fluent API
    89.4.4. Stub Runner with Spring
    89.5. Stub Runner Spring Cloud
    89.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    89.5.2. Additional Configuration
    89.6. Stub Runner Boot Application
    89.6.1. How to use it?
    Stub Runner Server
    Stub Runner Server Fat Jar
    Spring Cloud CLI
    89.6.2. Endpoints
    HTTP
    Messaging
    89.6.3. Example
    89.6.4. Stub Runner Boot with Service Discovery
    89.7. Stubs Per Consumer
    89.8. Common
    89.8.1. Common Properties for JUnit and Spring
    89.8.2. Stub Runner Stubs IDs
    89.9. Stub Runner Docker
    89.9.1. How to use it
    89.9.2. Example of client side usage in a non JVM project
    90. Stub Runner for Messaging
    90.1. Stub triggering
    90.1.1. Trigger by Label
    90.1.2. Trigger by Group and Artifact Ids
    90.1.3. Trigger by Artifact Ids
    90.1.4. Trigger All Messages
    90.2. Stub Runner Camel
    90.2.1. Adding the Runner to the Project
    90.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.3. Stub Runner Integration
    90.3.1. Adding the Runner to the Project
    90.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.4. Stub Runner Stream
    90.4.1. Adding the Runner to the Project
    90.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    90.5. Stub Runner Spring AMQP
    90.5.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    91. Contract DSL
    91.1. Limitations
    91.2. Common Top-Level elements
    91.2.1. Description
    91.2.2. Name
    91.2.3. Ignoring Contracts
    91.2.4. Passing Values from Files
    91.2.5. HTTP Top-Level Elements
    91.3. Request
    91.4. Response
    91.5. Dynamic properties
    91.5.1. Dynamic properties inside the body
    91.5.2. Regular expressions
    91.5.3. Passing Optional Parameters
    91.5.4. Executing Custom Methods on the Server Side
    91.5.5. Referencing the Request from the Response
    91.5.6. Registering Your Own WireMock Extension
    91.5.7. Dynamic Properties in the Matchers Sections
    91.6. JAX-RS Support
    91.7. Async Support
    91.8. Working with Context Paths
    91.9. Messaging Top-Level Elements
    91.9.1. Output Triggered by a Method
    91.9.2. Output Triggered by a Message
    91.9.3. Consumer/Producer
    91.9.4. Common
    91.10. Multiple Contracts in One File
    92. Customization
    92.1. Extending the DSL
    92.1.1. Common JAR
    92.1.2. Adding the Dependency to the Project
    92.1.3. Test the Dependency in the Project’s Dependencies
    92.1.4. Test a Dependency in the Plugin’s Dependencies
    92.1.5. Referencing classes in DSLs
    93. Using the Pluggable Architecture
    93.1. Custom Contract Converter
    93.1.1. Pact Converter
    93.1.2. Pact Contract
    93.1.3. Pact for Producers
    93.1.4. Pact for Consumers
    93.2. Using the Custom Test Generator
    93.3. Using the Custom Stub Generator
    93.4. Using the Custom Stub Runner
    93.5. Using the Custom Stub Downloader
    94. Spring Cloud Contract WireMock
    94.1. Registering Stubs Automatically
    94.2. Using Files to Specify the Stub Bodies
    94.3. Alternative: Using JUnit Rules
    94.4. Relaxed SSL Validation for Rest Template
    94.5. WireMock and Spring MVC Mocks
    94.6. Customization of WireMock configuration
    94.7. Generating Stubs using REST Docs
    94.8. Generating Contracts by Using REST Docs
    95. Migrations
    95.1. 1.0.x → 1.1.x
    95.1.1. New structure of generated stubs
    95.2. 1.1.x → 1.2.x
    95.2.1. Custom HttpServerStub
    95.2.2. New packages for generated tests
    95.2.3. New Methods in TemplateProcessor
    95.2.4. RestAssured 3.0
    96. Links
    XIV. Spring Cloud Vault
    97. Quick Start
    98. Client Side Usage
    98.1. Authentication
    99. Authentication methods
    99.1. Token authentication
    99.2. AppId authentication
    99.2.1. Custom UserId
    99.3. AppRole authentication
    99.4. AWS-EC2 authentication
    99.5. AWS-IAM authentication
    99.6. TLS certificate authentication
    99.7. Cubbyhole authentication
    99.8. Kubernetes authentication
    100. Secret Backends
    100.1. Generic Backend
    100.2. Consul
    100.3. RabbitMQ
    100.4. AWS
    101. Database backends
    101.1. Apache Cassandra
    101.2. MongoDB
    101.3. MySQL
    101.4. PostgreSQL
    102. Configure PropertySourceLocator behavior
    103. Service Registry Configuration
    104. Vault Client Fail Fast
    105. Vault Client SSL configuration
    106. Lease lifecycle management (renewal and revocation)
    XV. Appendix: Compendium of Configuration Properties

    Spring Cloud provides tools for developers to quickly build some of + Spring Cloud

    Spring Cloud

    Table of Contents

    1. Features
    I. Cloud Native Applications
    2. Spring Cloud Context: Application Context Services
    2.1. The Bootstrap Application Context
    2.2. Application Context Hierarchies
    2.3. Changing the Location of Bootstrap Properties
    2.4. Overriding the Values of Remote Properties
    2.5. Customizing the Bootstrap Configuration
    2.6. Customizing the Bootstrap Property Sources
    2.7. Environment Changes
    2.8. Refresh Scope
    2.9. Encryption and Decryption
    2.10. Endpoints
    3. Spring Cloud Commons: Common Abstractions
    3.1. @EnableDiscoveryClient
    3.1.1. Health Indicator
    3.2. ServiceRegistry
    3.2.1. ServiceRegistry Auto-Registration
    3.2.2. Service Registry Actuator Endpoint
    3.3. Spring RestTemplate as a Load Balancer Client
    3.3.1. Retrying Failed Requests
    3.4. Multiple RestTemplate objects
    3.5. Ignore Network Interfaces
    3.6. HTTP Client Factories
    II. Spring Cloud Config
    4. Quick Start
    4.1. Client Side Usage
    5. Spring Cloud Config Server
    5.1. Environment Repository
    5.1.1. Git Backend
    Placeholders in Git URI
    Pattern Matching and Multiple Repositories
    Authentication
    Authentication with AWS CodeCommit
    Git SSH configuration using properties
    Placeholders in Git Search Paths
    Force pull in Git Repositories
    Deleting untracked branches in Git Repositories
    5.1.2. Version Control Backend Filesystem Use
    5.1.3. File System Backend
    5.1.4. Vault Backend
    Multiple Properties Sources
    5.1.5. Sharing Configuration With All Applications
    File Based Repositories
    Vault Server
    5.1.6. JDBC Backend
    5.1.7. Composite Environment Repositories
    Custom Composite Environment Repositories
    5.1.8. Property Overrides
    5.2. Health Indicator
    5.3. Security
    5.4. Encryption and Decryption
    5.5. Key Management
    5.6. Creating a Key Store for Testing
    5.7. Using Multiple Keys and Key Rotation
    5.8. Serving Encrypted Properties
    6. Serving Alternative Formats
    7. Serving Plain Text
    8. Embedding the Config Server
    9. Push Notifications and Spring Cloud Bus
    10. Spring Cloud Config Client
    10.1. Config First Bootstrap
    10.2. Discovery First Bootstrap
    10.3. Config Client Fail Fast
    10.4. Config Client Retry
    10.5. Locating Remote Configuration Resources
    10.6. Security
    10.6.1. Health Indicator
    10.6.2. Providing A Custom RestTemplate
    10.6.3. Vault
    10.7. Vault
    10.7.1. Nested Keys In Vault
    III. Spring Cloud Netflix
    11. Service Discovery: Eureka Clients
    11.1. How to Include Eureka Client
    11.2. Registering with Eureka
    11.3. Authenticating with the Eureka Server
    11.4. Status Page and Health Indicator
    11.5. Registering a Secure Application
    11.6. Eureka’s Health Checks
    11.7. Eureka Metadata for Instances and Clients
    11.7.1. Using Eureka on Cloudfoundry
    11.7.2. Using Eureka on AWS
    11.7.3. Changing the Eureka Instance ID
    11.8. Using the EurekaClient
    11.8.1. EurekaClient without Jersey
    11.9. Alternatives to the native Netflix EurekaClient
    11.10. Why is it so Slow to Register a Service?
    11.11. Zones
    12. Service Discovery: Eureka Server
    12.1. How to Include Eureka Server
    12.2. How to Run a Eureka Server
    12.3. High Availability, Zones and Regions
    12.4. Standalone Mode
    12.5. Peer Awareness
    12.6. Prefer IP Address
    13. Circuit Breaker: Hystrix Clients
    13.1. How to Include Hystrix
    13.2. Propagating the Security Context or using Spring Scopes
    13.3. Health Indicator
    13.4. Hystrix Metrics Stream
    14. Circuit Breaker: Hystrix Dashboard
    15. Hystrix Timeouts And Ribbon Clients
    15.1. How to Include Hystrix Dashboard
    15.2. Turbine
    15.3. Turbine Stream
    16. Client Side Load Balancer: Ribbon
    16.1. How to Include Ribbon
    16.2. Customizing the Ribbon Client
    16.3. Customizing default for all Ribbon Clients
    16.4. Customizing the Ribbon Client using properties
    16.5. Using Ribbon with Eureka
    16.6. Example: How to Use Ribbon Without Eureka
    16.7. Example: Disable Eureka use in Ribbon
    16.8. Using the Ribbon API Directly
    16.9. Caching of Ribbon Configuration
    16.10. How to Configure Hystrix thread pools
    16.11. How to Provide a Key to Ribbon’s IRule
    17. Declarative REST Client: Feign
    17.1. How to Include Feign
    17.2. Overriding Feign Defaults
    17.3. Creating Feign Clients Manually
    17.4. Feign Hystrix Support
    17.5. Feign Hystrix Fallbacks
    17.6. Feign and @Primary
    17.7. Feign Inheritance Support
    17.8. Feign request/response compression
    17.9. Feign logging
    18. External Configuration: Archaius
    19. Router and Filter: Zuul
    19.1. How to Include Zuul
    19.2. Embedded Zuul Reverse Proxy
    19.3. Zuul Http Client
    19.4. Cookies and Sensitive Headers
    19.5. Ignored Headers
    19.6. Management Endpoints
    19.6.1. Routes Endpoint
    19.6.2. Filters Endpoint
    19.7. Strangulation Patterns and Local Forwards
    19.8. Uploading Files through Zuul
    19.9. Query String Encoding
    19.10. Plain Embedded Zuul
    19.11. Disable Zuul Filters
    19.12. Providing Hystrix Fallbacks For Routes
    19.13. Zuul Timeouts
    19.13.1. Service Discovery Configuration
    19.13.2. URL Configuration
    19.14. Rewriting Location header
    19.15. Zuul Developer Guide
    19.15.1. The Zuul Servlet
    19.15.2. Zuul RequestContext
    19.15.3. @EnableZuulProxy vs. @EnableZuulServer
    19.15.4. @EnableZuulServer Filters
    19.15.5. @EnableZuulProxy Filters
    19.15.6. Custom Zuul Filter examples
    19.15.7. How to Write a Pre Filter
    19.15.8. How to Write a Route Filter
    19.15.9. How to Write a Post Filter
    19.15.10. How Zuul Errors Work
    19.15.11. Zuul Eager Application Context Loading
    20. Polyglot support with Sidecar
    21. RxJava with Spring MVC
    22. Metrics: Spectator, Servo, and Atlas
    22.1. Dimensional vs. Hierarchical Metrics
    22.2. Default Metrics Collection
    22.3. Metrics Collection: Spectator
    22.3.1. Spectator Counter
    22.3.2. Spectator Timer
    22.3.3. Spectator Gauge
    22.3.4. Spectator Distribution Summaries
    22.4. Metrics Collection: Servo
    22.4.1. Creating Servo Monitors
    22.5. Metrics Backend: Atlas
    22.5.1. Global tags
    22.5.2. Using Atlas
    22.6. Retrying Failed Requests
    22.6.1. BackOff Policies
    22.6.2. Configuration
    22.6.3. Zuul
    23. HTTP Clients
    IV. Spring Cloud Stream
    24. Introducing Spring Cloud Stream
    25. Main Concepts
    25.1. Application Model
    25.1.1. Fat JAR
    25.2. The Binder Abstraction
    25.3. Persistent Publish-Subscribe Support
    25.4. Consumer Groups
    25.4.1. Durability
    25.5. Partitioning Support
    26. Programming Model
    26.1. Declaring and Binding Channels
    26.1.1. Triggering Binding Via @EnableBinding
    26.1.2. @Input and @Output
    Customizing Channel Names
    Source, Sink, and Processor
    26.1.3. Accessing Bound Channels
    Injecting the Bound Interfaces
    Injecting Channels Directly
    26.1.4. Producing and Consuming Messages
    Native Spring Integration Support
    Spring Integration Error Channel Support
    Message Channel Binders and Error Channels
    Using @StreamListener for Automatic Content Type Handling
    Using @StreamListener for dispatching messages to multiple methods
    26.1.5. Reactive Programming Support
    Reactor-based handlers
    RxJava 1.x support
    Reactive Sources
    26.1.6. Aggregation
    Configuring aggregate application
    Configuring binding service properties for non self contained aggregate application
    27. Binders
    27.1. Producers and Consumers
    27.2. Binder SPI
    27.3. Binder Detection
    27.3.1. Classpath Detection
    27.4. Multiple Binders on the Classpath
    27.5. Connecting to Multiple Systems
    27.6. Binder configuration properties
    28. Configuration Options
    28.1. Spring Cloud Stream Properties
    28.2. Binding Properties
    28.2.1. Properties for Use of Spring Cloud Stream
    28.2.2. Consumer properties
    28.2.3. Producer Properties
    28.3. Using dynamically bound destinations
    29. Content Type and Transformation
    29.1. MIME types
    29.2. MIME types and Java types
    29.3. Customizing message conversion
    29.4. @StreamListener and Message Conversion
    30. Schema evolution support
    30.1. Apache Avro Message Converters
    30.2. Converters with schema support
    30.3. Schema Registry Support
    30.4. Schema Registry Server
    30.4.1. Schema Registry Server API
    POST /
    GET /{subject}/{format}/{version}
    GET /{subject}/{format}
    GET /schemas/{id}
    DELETE /{subject}/{format}/{version}
    DELETE /schemas/{id}
    DELETE /{subject}
    30.5. Schema Registry Client
    30.5.1. Using Confluent’s Schema Registry
    30.5.2. Schema Registry Client properties
    30.6. Avro Schema Registry Client Message Converters
    30.6.1. Avro Schema Registry Message Converter properties
    30.7. Schema Registration and Resolution
    30.7.1. Schema Registration Process (Serialization)
    30.7.2. Schema Resolution Process (Deserialization)
    31. Inter-Application Communication
    31.1. Connecting Multiple Application Instances
    31.2. Instance Index and Instance Count
    31.3. Partitioning
    31.3.1. Configuring Output Bindings for Partitioning
    Spring-managed custom PartitionKeyExtractorClass implementations
    Configuring Input Bindings for Partitioning
    32. Testing
    32.1. Disabling the test binder autoconfiguration
    33. Health Indicator
    34. Metrics Emitter
    35. Samples
    36. Getting Started
    36.1. Deploying Stream applications on CloudFoundry
    V. Binder Implementations
    37. Apache Kafka Binder
    37.1. Usage
    37.2. Apache Kafka Binder Overview
    37.3. Configuration Options
    37.3.1. Kafka Binder Properties
    37.3.2. Kafka Consumer Properties
    37.3.3. Kafka Producer Properties
    37.3.4. Usage examples
    Example: Setting autoCommitOffset false and relying on manual acking.
    Example: security configuration
    Using the binder with Apache Kafka 0.10
    Excluding Kafka broker jar from the classpath of the binder based application
    37.4. Kafka Streams Binding Capabilities of Spring Cloud Stream
    37.4.1. Usage example of high level streams DSL
    37.4.2. Support for interactive queries
    37.4.3. Kafka Streams properties
    37.5. Error Channels
    37.6. Kafka Metrics
    37.7. Dead-Letter Topic Processing
    38. RabbitMQ Binder
    38.1. Usage
    38.2. RabbitMQ Binder Overview
    38.3. Configuration Options
    38.3.1. RabbitMQ Binder Properties
    38.3.2. RabbitMQ Consumer Properties
    38.3.3. Rabbit Producer Properties
    38.4. Retry With the RabbitMQ Binder
    38.4.1. Overview
    38.4.2. Putting it All Together
    38.5. Error Channels
    38.6. Dead-Letter Queue Processing
    38.6.1. Non-Partitioned Destinations
    38.6.2. Partitioned Destinations
    republishToDlq=false
    republishToDlq=true
    VI. Spring Cloud Bus
    39. Quick Start
    40. Addressing an Instance
    41. Addressing all instances of a service
    42. Application Context ID must be unique
    43. Customizing the Message Broker
    44. Tracing Bus Events
    45. Broadcasting Your Own Events
    45.1. Registering events in custom packages
    VII. Spring Cloud Sleuth
    46. Introduction
    46.1. Terminology
    46.2. Purpose
    46.2.1. Distributed tracing with Zipkin
    46.2.2. Visualizing errors
    46.2.3. Live examples
    46.2.4. Log correlation
    JSON Logback with Logstash
    46.2.5. Propagating Span Context
    Baggage vs. Span Tags
    46.3. Adding to the project
    46.3.1. Only Sleuth (log correlation)
    46.3.2. Sleuth with Zipkin via HTTP
    46.3.3. Sleuth with Zipkin via RabbitMQ or Kafka
    47. Additional resources
    48. Features
    49. Sampling
    50. Instrumentation
    51. Span lifecycle
    51.1. Creating and closing spans
    51.2. Continuing spans
    51.3. Creating spans with an explicit parent
    52. Naming spans
    52.1. @SpanName annotation
    52.2. toString() method
    53. Managing spans with annotations
    53.1. Rationale
    53.2. Creating new spans
    53.3. Continuing spans
    53.4. More advanced tag setting
    53.4.1. Custom extractor
    53.4.2. Resolving expressions for value
    53.4.3. Using toString method
    54. Customizations
    54.1. Spring Integration
    54.2. HTTP
    54.3. Example
    54.4. TraceFilter
    54.5. Custom SA tag in Zipkin
    54.6. Custom service name
    54.7. Customization of reported spans
    54.8. Host locator
    55. Sending spans to Zipkin
    56. Span Data as Messages
    56.1. Zipkin Consumer
    56.2. Custom Consumer
    57. Metrics
    58. Integrations
    58.1. Runnable and Callable
    58.2. Hystrix
    58.2.1. Custom Concurrency Strategy
    58.2.2. Manual Command setting
    58.3. RxJava
    58.4. HTTP integration
    58.4.1. HTTP Filter
    58.4.2. HandlerInterceptor
    58.4.3. Async Servlet support
    58.5. HTTP client integration
    58.5.1. Synchronous Rest Template
    58.5.2. Asynchronous Rest Template
    Multiple Asynchronous Rest Templates
    58.5.3. Traverson
    58.6. Feign
    58.7. Asynchronous communication
    58.7.1. @Async annotated methods
    58.7.2. @Scheduled annotated methods
    58.7.3. Executor, ExecutorService and ScheduledExecutorService
    Customization of Executors
    58.8. Messaging
    58.9. Zuul
    58.10. Spring Cloud Function
    59. Running examples
    VIII. Spring Cloud Consul
    60. Install Consul
    61. Consul Agent
    62. Service Discovery with Consul
    62.1. How to activate
    62.2. Registering with Consul
    62.3. HTTP Health Check
    62.3.1. Metadata and Consul tags
    62.3.2. Making the Consul Instance ID Unique
    62.4. Looking up services
    62.4.1. Using Ribbon
    62.4.2. Using the DiscoveryClient
    63. Distributed Configuration with Consul
    63.1. How to activate
    63.2. Customizing
    63.3. Config Watch
    63.4. YAML or Properties with Config
    63.5. git2consul with Config
    63.6. Fail Fast
    64. Consul Retry
    65. Spring Cloud Bus with Consul
    65.1. How to activate
    66. Circuit Breaker with Hystrix
    67. Hystrix metrics aggregation with Turbine and Consul
    IX. Spring Cloud Zookeeper
    68. Install Zookeeper
    69. Service Discovery with Zookeeper
    69.1. How to activate
    69.2. Registering with Zookeeper
    69.3. Using the DiscoveryClient
    70. Using Spring Cloud Zookeeper with Spring Cloud Netflix Components
    70.1. Ribbon with Zookeeper
    71. Spring Cloud Zookeeper and Service Registry
    71.1. Instance Status
    72. Zookeeper Dependencies
    72.1. Using the Zookeeper Dependencies
    72.2. How to activate Zookeeper Dependencies
    72.3. Setting up Zookeeper Dependencies
    72.3.1. Aliases
    72.3.2. Path
    72.3.3. Load balancer type
    72.3.4. Content-Type template and version
    72.3.5. Default headers
    72.3.6. Obligatory dependencies
    72.3.7. Stubs
    72.4. Configuring Spring Cloud Zookeeper Dependencies
    73. Spring Cloud Zookeeper Dependency Watcher
    73.1. How to activate
    73.2. Registering a listener
    73.3. Presence Checker
    74. Distributed Configuration with Zookeeper
    74.1. How to activate
    74.2. Customizing
    74.3. ACLs
    X. Spring Cloud Security
    75. Quickstart
    75.1. OAuth2 Single Sign On
    75.2. OAuth2 Protected Resource
    76. More Detail
    76.1. Single Sign On
    76.2. Token Relay
    76.2.1. Client Token Relay
    76.2.2. Client Token Relay in Zuul Proxy
    76.2.3. Resource Server Token Relay
    77. Configuring Authentication Downstream of a Zuul Proxy
    XI. Spring Cloud for Cloud Foundry
    78. Discovery
    79. Single Sign On
    XII. Spring Cloud Contract
    80. Spring Cloud Contract
    81. Spring Cloud Contract Verifier Introduction
    81.1. Why a Contract Verifier?
    81.1.1. Testing issues
    81.2. Purposes
    81.3. How It Works
    81.3.1. Defining the contract
    81.3.2. Client Side
    81.3.3. Server Side
    81.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    81.4.1. Technical note
    81.4.2. Consumer side (Loan Issuance)
    81.4.3. Producer side (Fraud Detection server)
    81.4.4. Consumer Side (Loan Issuance) Final Step
    81.5. Dependencies
    81.6. Additional Links
    81.6.1. Spring Cloud Contract video
    81.6.2. Readings
    81.7. Samples
    82. Spring Cloud Contract FAQ
    82.1. Why use Spring Cloud Contract Verifier and not X ?
    82.2. I don’t want to write a contract in Groovy!
    82.3. What is this value(consumer(), producer()) ?
    82.4. How to do Stubs versioning?
    82.4.1. API Versioning
    82.4.2. JAR versioning
    82.4.3. Dev or prod stubs
    82.5. Common repo with contracts
    82.5.1. Repo structure
    82.5.2. Workflow
    82.5.3. Consumer
    82.5.4. Producer
    82.6. Can I have multiple base classes for tests?
    82.7. How can I debug the request/response being sent by the generated tests client?
    82.7.1. How can I debug the mapping/request/response being sent by WireMock?
    82.7.2. How can I see what got registered in the HTTP server stub?
    82.7.3. Can I reference the request from the response?
    82.7.4. Can I reference text from file?
    83. Spring Cloud Contract Verifier Setup
    83.1. Gradle Project
    83.1.1. Prerequisites
    83.1.2. Add Gradle Plugin with Dependencies
    83.1.3. Gradle and Rest Assured 2.0
    83.1.4. Snapshot Versions for Gradle
    83.1.5. Add stubs
    83.1.6. Run the Plugin
    83.1.7. Default Setup
    83.1.8. Configure Plugin
    83.1.9. Configuration Options
    83.1.10. Single Base Class for All Tests
    83.1.11. Different Base Classes for Contracts
    83.1.12. Invoking Generated Tests
    83.1.13. Spring Cloud Contract Verifier on the Consumer Side
    83.2. Maven Project
    83.2.1. Add maven plugin
    83.2.2. Maven and Rest Assured 2.0
    83.2.3. Snapshot versions for Maven
    83.2.4. Add stubs
    83.2.5. Run plugin
    83.2.6. Configure plugin
    83.2.7. Configuration Options
    83.2.8. Single Base Class for All Tests
    83.2.9. Different base classes for contracts
    83.2.10. Invoking generated tests
    83.2.11. Maven Plugin and STS
    83.3. Stubs and Transitive Dependencies
    83.4. CI Server setup
    83.5. Scenarios
    83.6. Docker Project
    83.6.1. Short intro to Maven, JARs and Binary storage
    83.6.2. How it works
    Environment Variables
    83.6.3. Example of usage
    83.6.4. Server side (nodejs)
    84. Spring Cloud Contract Verifier Messaging
    84.1. Integrations
    84.2. Manual Integration Testing
    84.3. Publisher-Side Test Generation
    84.3.1. Scenario 1: No Input Message
    84.3.2. Scenario 2: Output Triggered by Input
    84.3.3. Scenario 3: No Output Message
    84.4. Consumer Stub Generation
    85. Spring Cloud Contract Stub Runner
    85.1. Snapshot versions
    85.2. Publishing Stubs as JARs
    85.3. Stub Runner Core
    85.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    85.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    85.4. Stub Runner JUnit Rule
    85.4.1. Maven settings
    85.4.2. Providing fixed ports
    85.4.3. Fluent API
    85.4.4. Stub Runner with Spring
    85.5. Stub Runner Spring Cloud
    85.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    85.5.2. Additional Configuration
    85.6. Stub Runner Boot Application
    85.6.1. How to use it?
    Stub Runner Server
    Stub Runner Server Fat Jar
    Spring Cloud CLI
    85.6.2. Endpoints
    HTTP
    Messaging
    85.6.3. Example
    85.6.4. Stub Runner Boot with Service Discovery
    85.7. Stubs Per Consumer
    85.8. Common
    85.8.1. Common Properties for JUnit and Spring
    85.8.2. Stub Runner Stubs IDs
    85.9. Stub Runner Docker
    85.9.1. How to use it
    85.9.2. Example of client side usage in a non JVM project
    86. Stub Runner for Messaging
    86.1. Stub triggering
    86.1.1. Trigger by Label
    86.1.2. Trigger by Group and Artifact Ids
    86.1.3. Trigger by Artifact Ids
    86.1.4. Trigger All Messages
    86.2. Stub Runner Camel
    86.2.1. Adding the Runner to the Project
    86.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.3. Stub Runner Integration
    86.3.1. Adding the Runner to the Project
    86.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.4. Stub Runner Stream
    86.4.1. Adding the Runner to the Project
    86.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    86.5. Stub Runner Spring AMQP
    86.5.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    87. Contract DSL
    87.1. Limitations
    87.2. Common Top-Level elements
    87.2.1. Description
    87.2.2. Name
    87.2.3. Ignoring Contracts
    87.2.4. Passing Values from Files
    87.2.5. HTTP Top-Level Elements
    87.3. Request
    87.4. Response
    87.5. Dynamic properties
    87.5.1. Dynamic properties inside the body
    87.5.2. Regular expressions
    87.5.3. Passing Optional Parameters
    87.5.4. Executing Custom Methods on the Server Side
    87.5.5. Referencing the Request from the Response
    87.5.6. Registering Your Own WireMock Extension
    87.5.7. Dynamic Properties in the Matchers Sections
    87.6. JAX-RS Support
    87.7. Async Support
    87.8. Working with Context Paths
    87.9. Messaging Top-Level Elements
    87.9.1. Output Triggered by a Method
    87.9.2. Output Triggered by a Message
    87.9.3. Consumer/Producer
    87.9.4. Common
    87.10. Multiple Contracts in One File
    88. Customization
    88.1. Extending the DSL
    88.1.1. Common JAR
    88.1.2. Adding the Dependency to the Project
    88.1.3. Test the Dependency in the Project’s Dependencies
    88.1.4. Test a Dependency in the Plugin’s Dependencies
    88.1.5. Referencing classes in DSLs
    89. Using the Pluggable Architecture
    89.1. Custom Contract Converter
    89.1.1. Pact Converter
    89.1.2. Pact Contract
    89.1.3. Pact for Producers
    89.1.4. Pact for Consumers
    89.2. Using the Custom Test Generator
    89.3. Using the Custom Stub Generator
    89.4. Using the Custom Stub Runner
    89.5. Using the Custom Stub Downloader
    90. Spring Cloud Contract WireMock
    90.1. Registering Stubs Automatically
    90.2. Using Files to Specify the Stub Bodies
    90.3. Alternative: Using JUnit Rules
    90.4. Relaxed SSL Validation for Rest Template
    90.5. WireMock and Spring MVC Mocks
    90.6. Customization of WireMock configuration
    90.7. Generating Stubs using REST Docs
    90.8. Generating Contracts by Using REST Docs
    91. Migrations
    91.1. 1.0.x → 1.1.x
    91.1.1. New structure of generated stubs
    91.2. 1.1.x → 1.2.x
    91.2.1. Custom HttpServerStub
    91.2.2. New packages for generated tests
    91.2.3. New Methods in TemplateProcessor
    91.2.4. RestAssured 3.0
    92. Links
    XIII. Spring Cloud Vault
    93. Quick Start
    94. Client Side Usage
    94.1. Authentication
    95. Authentication methods
    95.1. Token authentication
    95.2. AppId authentication
    95.2.1. Custom UserId
    95.3. AppRole authentication
    95.4. AWS-EC2 authentication
    95.5. AWS-IAM authentication
    95.6. TLS certificate authentication
    95.7. Cubbyhole authentication
    95.8. Kubernetes authentication
    96. Secret Backends
    96.1. Generic Backend
    96.2. Consul
    96.3. RabbitMQ
    96.4. AWS
    97. Database backends
    97.1. Apache Cassandra
    97.2. MongoDB
    97.3. MySQL
    97.4. PostgreSQL
    98. Configure PropertySourceLocator behavior
    99. Service Registry Configuration
    100. Vault Client Fail Fast
    101. Vault Client SSL configuration
    102. Lease lifecycle management (renewal and revocation)
    XIV. Appendix: Compendium of Configuration Properties

    Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus). Coordination of @@ -8,7 +8,7 @@ distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data -centres, and managed platforms such as Cloud Foundry.

    Version: 2.0.0.BUILD-SNAPSHOT

    1. Features

    Spring Cloud focuses on providing good out of box experience for typical use cases +centres, and managed platforms such as Cloud Foundry.

    Version: 1.3.8.RELEASE

    1. Features

    Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.

    • Distributed/versioned configuration
    • Service registration and discovery
    • Routing
    • Service-to-service calls
    • Load balancing
    • Circuit Breakers
    • Distributed messaging

    Part I. Cloud Native Applications

    Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. A related discipline is that of building 12-factor Apps in which development practices are aligned with delivery and operations goals, for instance by using declarative programming and management and monitoring. Spring Cloud facilitates these styles of development in a number of specific ways and the starting point is a set of features that all components in a distributed system either need or need easy access to when required.

    Many of those features are covered by Spring Boot, which we build on in Spring Cloud. Some more are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. Spring Cloud Context provides utilities and special services for the ApplicationContext of a Spring Cloud application (bootstrap context, encryption, refresh scope and environment endpoints). Spring Cloud Commons is a set of abstractions and common classes used in different Spring Cloud implementations (eg. Spring Cloud Netflix vs. Spring Cloud Consul).

    If you are getting an exception due to "Illegal key size" and you are using Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:

    Extract files into JDK/jre/lib/security folder (whichever version of JRE/JDK x64/x86 you are using).

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    2. Spring Cloud Context: Application Context Services

    Spring Boot has an opinionated view of how to build an application with Spring: for instance it has conventional locations for common configuration file, and endpoints for common management and monitoring @@ -343,7 +343,7 @@ HTTP client and OkHttpClientConnectionPoolFactory f your own implementation of these beans if you would like to customize how the HTTP clients are created in downstream projects. You can also disable the creation of these beans by setting spring.cloud.httpclientfactories.apache.enabled or spring.cloud.httpclientfactories.ok.enabled to -false.

    Part II. Spring Cloud Config

    2.0.0.BUILD-SNAPSHOT

    Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

    4. Quick Start

    Start the server:

    $ cd spring-cloud-config-server
+false.

    Part II. Spring Cloud Config

    1.3.8.RELEASE

    Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

    4. Quick Start

    Start the server:

    $ cd spring-cloud-config-server
 $ ../mvnw spring-boot:run

    The server is a Spring Boot application so you can run it from your IDE instead if you prefer (the main class is ConfigServerApplication). Then try out a client:

    $ curl localhost:8888/foo/development
@@ -1258,7 +1258,7 @@ in bootstrap.yml.
    bootstrap.yml. 
       token: YourVaultToken

    10.7 Vault

    10.7.1 Nested Keys In Vault

    Vault supports the ability to nest keys in a value stored in Vault. For example

    echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -

    This command will write a JSON object to your Vault. To access these values in Spring you would use the traditional dot(.) annotation. For example

    @Value("${appA.secret}")
-String name = "World";

    The above code would set the name variable to appAsecret.

    Part III. Spring Cloud Netflix

    2.0.0.BUILD-SNAPSHOT

    This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration +String name = "World";

    The above code would set the name variable to appAsecret.

    Part III. Spring Cloud Netflix

    1.3.8.RELEASE

    This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The @@ -4352,7 +4352,7 @@ package of BusConfiguration.

    You can also exp }

    All examples of @RemoteApplicationEventScan above are equivalent, in that the com.acme package will be registered by explicitly specifying the packages on @RemoteApplicationEventScan. Note, you can specify multiple base -packages to scan.

    Part VII. Spring Cloud Sleuth

    Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer

    2.0.0.BUILD-SNAPSHOT

    46. Introduction

    Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud.

    46.1 Terminology

    Spring Cloud Sleuth borrows Dapper’s terminology.

    Span: The basic unit of work. For example, sending an RPC is a new span, as is sending a response to an +packages to scan.

    Part VII. Spring Cloud Sleuth

    Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer

    1.3.8.RELEASE

    46. Introduction

    Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud.

    46.1 Terminology

    Spring Cloud Sleuth borrows Dapper’s terminology.

    Span: The basic unit of work. For example, sending an RPC is a new span, as is sending a response to an RPC. Span’s are identified by a unique 64-bit ID for the span and another 64-bit ID for the trace the span is a part of. Spans also have other data, such as descriptions, timestamped events, key-value annotations (tags), the ID of the span that caused them, and process ID’s (normally IP address).

    Spans are started and stopped, and they keep track of their timing information. Once you create a @@ -5180,7 +5180,7 @@ Just define a Reporter<Span> bean as presente } }; } -}

    59. Running examples

    You can find the running examples deployed in the Pivotal Web Services. Check them out in the following links:

    Part VIII. Spring Cloud Consul

    2.0.0.BUILD-SNAPSHOT

    This project provides Consul integrations for Spring Boot apps through autoconfiguration +}

    59. Running examples

    You can find the running examples deployed in the Pivotal Web Services. Check them out in the following links:

    Part VIII. Spring Cloud Consul

    1.3.8.RELEASE

    This project provides Consul integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with Consul based components. The @@ -5448,83 +5448,7 @@ comma-separated list set as the value of the property 

    org.springframework.cloud.bootstrap.BootstrapConfiguration=\
 my.project.CustomCuratorFrameworkConfig,\
 my.project.DefaultCuratorFrameworkConfig

    -

    Part X. Spring Boot Cloud CLI

    Spring Boot CLI provides Spring -Boot command line features for Spring -Cloud. You can write Groovy scripts to run Spring Cloud component -applications (e.g. @EnableEurekaServer). You can also easily do -things like encryption and decryption to support Spring Cloud Config -clients with secret configuration values. With the Launcher CLI you -can launch services like Eureka, Zipkin, Config Server -conveniently all at once from the command line (very useful at -development time).

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    75. Installation

    To install, make -sure you have -Spring Boot CLI -(1.5.2 or better):

    $ spring version
-Spring CLI v1.5.4.RELEASE

    E.g. for SDKMan users

    $ sdk install springboot 1.5.4.RELEASE
-$ sdk use springboot 1.5.4.RELEASE

    and install the Spring Cloud plugin

    $ mvn install
-$ spring install org.springframework.cloud:spring-cloud-cli:1.4.0.BUILD-SNAPSHOT
    [Important]Important

    Prerequisites: to use the encryption and decryption features -you need the full-strength JCE installed in your JVM (it’s not there by default). -You can download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" -from Oracle, and follow instructions for installation (essentially replace the 2 policy files -in the JRE lib/security directory with the ones that you downloaded).

    76. Running Spring Cloud Services in Development

    The Launcher CLI can be used to run common services like Eureka, -Config Server etc. from the command line. To list the available -services you can do spring cloud --list, and to launch a default set -of services just spring cloud. To choose the services to deploy, -just list them on the command line, e.g.

    $ spring cloud eureka configserver h2 kafka stubrunner zipkin

    Summary of supported deployables:

    ServiceNameAddressDescription

    eureka

    Eureka Server

    http://localhost:8761

    Eureka server for service registration and discovery. All the other services show up in its catalog by default.

    configserver

    Config Server

    http://localhost:8888

    Spring Cloud Config Server running in the "native" profile and serving configuration from the local directory ./launcher

    h2

    H2 Database

    http://localhost:9095 (console), jdbc:h2:tcp://localhost:9096/{data}

    Relation database service. Use a file path for {data} (e.g. ./target/test) when you connect. Remember that you can add ;MODE=MYSQL or ;MODE=POSTGRESQL to connect with compatibility to other server types.

    kafka

    Kafka Broker

    http://localhost:9091 (actuator endpoints), localhost:9092

    		 

    hystrixdashboard

    Hystrix Dashboard

    http://localhost:7979

    Any Spring Cloud app that declares Hystrix circuit breakers publishes metrics on /hystrix.stream. Type that address into the dashboard to visualize all the metrics,

    dataflow

    Dataflow Server

    http://localhost:9393

    Spring Cloud Dataflow server with UI at /admin-ui. Connect the Dataflow shell to target at root path.

    zipkin

    Zipkin Server

    http://localhost:9411

    Zipkin Server with UI for visualizing traces. Stores span data in memory and accepts them via HTTP POST of JSON data.

    stubrunner

    Stub Runner Boot

    http://localhost:8750

    Downloads WireMock stubs, starts WireMock and feeds the started servers with stored stubs. Pass stubrunner.ids to pass stub coordinates and then go to http://localhost:8750/stubs.

    Each of these apps can be configured using a local YAML file with the same name (in the current -working directory or a subdirectory called "config" or in ~/.spring-cloud). E.g. in configserver.yml you might want to -do something like this to locate a local git repository for the backend:

    configserver.yml.  -

    spring:
-  profiles:
-    active: git
-  cloud:
-    config:
-      server:
-        git:
-          uri: file://${user.home}/dev/demo/config-repo

    -

    E.g. in Stub Runner app you could fetch stubs from your local .m2 in the following way.

    stubrunner.yml.  -

    stubrunner:
-  workOffline: true
-  ids:
-    - com.example:beer-api-producer:+:9876

    -

    76.1 Adding Additional Applications

    Additional applications can be added to ./config/cloud.yml (not -./config.yml because that would replace the defaults), e.g. with

    config/cloud.yml.  -

    spring:
-  cloud:
-    launcher:
-      deployables:
-        source:
-          coordinates: maven://com.example:source:0.0.1-SNAPSHOT
-          port: 7000
-        sink:
-          coordinates: maven://com.example:sink:0.0.1-SNAPSHOT
-          port: 7001

    -

    when you list the apps:

    $ spring cloud --list
-source sink configserver dataflow eureka h2 hystrixdashboard kafka stubrunner zipkin

    (notice the additional apps at the start of the list).

    77. Writing Groovy Scripts and Running Applications

    Spring Cloud CLI has support for most of the Spring Cloud declarative -features, such as the @Enable* class of annotations. For example, -here is a fully functional Eureka server

    app.groovy.  -

    @EnableEurekaServer
-class Eureka {}

    -

    which you can run from the command line like this

    $ spring run app.groovy

    To include additional dependencies, often it suffices just to add the -appropriate feature-enabling annotation, e.g. @EnableConfigServer, -@EnableOAuth2Sso or @EnableEurekaClient. To manually include a -dependency you can use a @Grab with the special "Spring Boot" short -style artifact co-ordinates, i.e. with just the artifact ID (no need -for group or version information), e.g. to set up a client app to -listen on AMQP for management events from the Spring CLoud Bus:

    app.groovy.  -

    @Grab('spring-cloud-starter-bus-amqp')
-@RestController
-class Service {
-  @RequestMapping('/')
-  def home() { [message: 'Hello'] }
-}

    -

    78. Encryption and Decryption

    The Spring Cloud CLI comes with an "encrypt" and a "decrypt" -command. Both accept arguments in the same form with a key specified -as a mandatory "--key", e.g.

    $ spring encrypt mysecret --key foo
-682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
-$ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
-mysecret

    To use a key in a file (e.g. an RSA public key for encyption) prepend -the key value with "@" and provide the file path, e.g.

    $ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
-AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...

    Part XI. Spring Cloud Security

    Spring Cloud Security offers a set of primitives for building secure +

    Unresolved directive in spring-cloud.adoc - include::../../../../cli/docs/src/main/asciidoc/spring-cloud-cli.adoc[]

    Part X. Spring Cloud Security

    Spring Cloud Security offers a set of primitives for building secure applications and services with minimum fuss. A declarative model which can be heavily configured externally (or centrally) lends itself to the implementation of large systems of co-operating, remote components, @@ -5532,7 +5456,7 @@ usually with a central indentity management service. It is also extremely easy to use in a service platform like Cloud Foundry. Building on Spring Boot and Spring Security OAuth2 we can quickly create systems that implement common patterns like single sign on, token relay and token -exchange.

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    79. Quickstart

    79.1 OAuth2 Single Sign On

    Here’s a Spring Cloud "Hello World" app with HTTP Basic +exchange.

    [Note]Note

    Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.

    75. Quickstart

    75.1 OAuth2 Single Sign On

    Here’s a Spring Cloud "Hello World" app with HTTP Basic authentication and a single user account:

    app.groovy.  

    @Grab('spring-boot-starter-security')
 @Controller
@@ -5582,7 +5506,7 @@ decide what the defaults should be, usually depending on the settings in
 the client registration that it holds.
    [Note]Note
    The examples above are all Groovy scripts. If you want to write the
 same code in Java (or Groovy) you need to add Spring Security OAuth2
 to the classpath (e.g. see the
-sample here).

    79.2 OAuth2 Protected Resource

    You want to protect an API resource with an OAuth2 token? Here’s a +sample here).

    75.2 OAuth2 Protected Resource

    You want to protect an API resource with an OAuth2 token? Here’s a simple example (paired with the client above):

    app.groovy.  

    @Grab('spring-cloud-starter-security')
 @RestController
@@ -5601,12 +5525,12 @@ simple example (paired with the client above):
    app.groovy. 
     resource:
       userInfoUri: https://api.github.com/user
       preferTokenInfo: false

    -

    80. More Detail

    80.1 Single Sign On

    [Note]Note

    All of the OAuth2 SSO and resource server features moved to Spring Boot +

    76. More Detail

    76.1 Single Sign On

    [Note]Note

    All of the OAuth2 SSO and resource server features moved to Spring Boot in version 1.3. You can find documentation in the -Spring Boot user guide.

    80.2 Token Relay

    A Token Relay is where an OAuth2 consumer acts as a Client and +Spring Boot user guide.

    76.2 Token Relay

    A Token Relay is where an OAuth2 consumer acts as a Client and forwards the incoming token to outgoing resource requests. The consumer can be a pure Client (like an SSO application) or a Resource -Server.

    80.2.1 Client Token Relay

    If your app is a user facing OAuth2 client (i.e. has declared +Server.

    76.2.1 Client Token Relay

    If your app is a user facing OAuth2 client (i.e. has declared @EnableOAuth2Sso or @EnableOAuth2Client) then it has an OAuth2ClientContext in request scope from Spring Boot. You can create your own OAuth2RestTemplate from this context and an @@ -5617,7 +5541,7 @@ Security and Spring Boot.)

    OAuth2ProtectedResourceDetails automatically if you are using client_credentials tokens. In that case you need to create your own ClientCredentialsResourceDetails and configure it with -@ConfigurationProperties("security.oauth2.client").

    80.2.2 Client Token Relay in Zuul Proxy

    If your app also has a +@ConfigurationProperties("security.oauth2.client").

    76.2.2 Client Token Relay in Zuul Proxy

    If your app also has a Spring Cloud Zuul embedded reverse proxy (using @EnableZuulProxy) then you can ask it to forward OAuth2 access tokens downstream to the services @@ -5640,7 +5564,7 @@ a ZuulFilter, which itself is activated because Zuu classpath (via @EnableZuulProxy). The filter just extracts an access token from the currently authenticated user, -and puts it in a request header for the downstream requests.

    80.2.3 Resource Server Token Relay

    If your app has @EnableResourceServer you might want to relay the +and puts it in a request header for the downstream requests.

    76.2.3 Resource Server Token Relay

    If your app has @EnableResourceServer you might want to relay the incoming token downstream to other services. If you use a RestTemplate to contact the downstream services then this is just a matter of how to create the template with the right context.

    If your service uses UserInfoTokenServices to authenticate incoming @@ -5682,7 +5606,7 @@ choice, since you might want to act as yourself, rather than the client that sent you the token), then you only need to create your own OAuth2Context instead of autowiring the default one.

    Feign clients will also pick up an interceptor that uses the OAuth2ClientContext if it is available, so they should also do a -token relay anywhere where a RestTemplate would.

    81. Configuring Authentication Downstream of a Zuul Proxy

    You can control the authorization behaviour downstream of an +token relay anywhere where a RestTemplate would.

    77. Configuring Authentication Downstream of a Zuul Proxy

    You can control the authorization behaviour downstream of an @EnableZuulProxy through the proxy.auth.* settings. Example:

    application.yml.  

    proxy:
   auth:
@@ -5696,7 +5620,7 @@ just passed downstream), and the "recommendations" service has its
 authorization header removed. The default behaviour is to do a token
 relay if there is a token available, and passthru otherwise.
    See
 
-ProxyAuthenticationProperties for full details.

    Part XII. Spring Cloud for Cloud Foundry

    Spring Cloud for Cloudfoundry makes it easy to run +ProxyAuthenticationProperties for full details.

    Part XI. Spring Cloud for Cloud Foundry

    Spring Cloud for Cloudfoundry makes it easy to run Spring Cloud apps in Cloud Foundry (the Platform as a Service). Cloud Foundry has the notion of a "service", which is @@ -5712,7 +5636,7 @@ implementation of Spring Cloud Commons DiscoveryClientDiscoveryClient directly or via a LoadBalancerClient (also *.url if you are not connecting to Pivotal Web Services).

    The first time you use it the discovery client might be slow owing to -the fact that it has to get an access token from Cloud Foundry.

    82. Discovery

    Here’s a Spring Cloud app with Cloud Foundry discovery:

    app.groovy.  +the fact that it has to get an access token from Cloud Foundry.

    78. Discovery

    Here’s a Spring Cloud app with Cloud Foundry discovery:

    app.groovy.  

    @Grab('org.springframework.cloud:spring-cloud-cloudfoundry')
 @RestController
 @EnableDiscoveryClient
@@ -5731,7 +5655,7 @@ the fact that it has to get an access token from Cloud Foundry.

    It will show its app name in the home page.

    The DiscoveryClient can lists all the apps in a space, according to the credentials it is authenticated with, where the space defaults to the one the client is running in (if any). If neither org nor space -are configured, they default per the user’s profile in Cloud Foundry.

    83. Single Sign On

    [Note]Note

    All of the OAuth2 SSO and resource server features moved to Spring Boot +are configured, they default per the user’s profile in Cloud Foundry.

    79. Single Sign On

    [Note]Note

    All of the OAuth2 SSO and resource server features moved to Spring Boot in version 1.3. You can find documentation in the Spring Boot user guide.

    This project provides automatic binding from CloudFoundry service credentials to the Spring Boot features. If you have a CloudFoundry @@ -5739,12 +5663,12 @@ service called "sso", for instance, with credentials containing "client_id", "client_secret" and "auth_domain", it will bind automatically to the Spring OAuth2 client that you enable with @EnableOAuth2Sso (from Spring Boot). The name of the service can be -parameterized using spring.oauth2.sso.serviceId.

    Part XIII. Spring Cloud Contract

    _Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, -Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

    2.0.0.BUILD-SNAPSHOT

    84. Spring Cloud Contract

    You need confidence when pushing new features to a new application or service in a +parameterized using spring.oauth2.sso.serviceId.

    Part XII. Spring Cloud Contract

    _Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, +Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

    1.3.8.RELEASE

    80. Spring Cloud Contract

    You need confidence when pushing new features to a new application or service in a distributed system. This project provides support for Consumer Driven Contracts and service schemas in Spring applications (for both HTTP and message-based interactions), covering a range of options for writing tests, publishing them as assets, and asserting -that a contract is kept by producers and consumers.

    85. Spring Cloud Contract Verifier Introduction

    [Tip]Tip

    The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski +that a contract is kept by producers and consumers.

    81. Spring Cloud Contract Verifier Introduction

    [Tip]Tip

    The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski (codearte.io)

    Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture.

    Spring Cloud Contract Verifier ships with Contract Definition Language (CDL). Contract definitions are used to produce the following resources:

    • JSON stub definitions to be used by WireMock when doing integration testing on the @@ -5753,7 +5677,7 @@ produced by Spring Cloud Contract Verifier.
    • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
    • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.

    85.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    85.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

    81.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    81.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with @@ -5762,13 +5686,13 @@ created. The main idea is to give you very fast feedback, without the need to se whole world of microservices. If you work on stubs, then the only applications you need are those that your application directly uses.

      Stubbed Services

      Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they -were tested against the producer’s side. In short, you can trust those stubs.

    85.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly +were tested against the producer’s side. In short, you can trust those stubs.

    81.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both sides.
    • To generate boilerplate test code to be used on the server side.
    [Important]Important

    Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts, one for the positive case and one for the negative case. Contract tests are -used to test contracts between applications and not to simulate full behavior.

    85.3 How It Works

    This section explores how Spring Cloud Contract Verifier with Stub Runner works.

    85.3.1 Defining the contract

    As consumers of services, we need to define what exactly we want to achieve. We need to +used to test contracts between applications and not to simulate full behavior.

    81.3 How It Works

    This section explores how Spring Cloud Contract Verifier with Stub Runner works.

    81.3.1 Defining the contract

    As consumers of services, we need to define what exactly we want to achieve. We need to formulate our expectations. That is why we write contracts.

    Assume that you want to send a request containing the ID of a client company and the amount it wants to borrow from us. You also want to send it to the /fraudcheck url via the PUT method.

    Groovy DSL.  @@ -5882,7 +5806,7 @@ response: # (7) #(9) - and JSON body equal to # { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" } #(10) - with header `Content-Type` equal to `application/json;charset=UTF-8`

    -

    85.3.2 Client Side

    Spring Cloud Contract generates stubs, which you can use during client-side testing. +

    81.3.2 Client Side

    Spring Cloud Contract generates stubs, which you can use during client-side testing. You get a running WireMock instance/Messaging route that simulates the service. You would like to feed that instance with a proper stub definition.

    At some point in time, you need to send a request to the Fraud Detection service.

    ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
@@ -5893,7 +5817,7 @@ You would like to feed that instance with a proper stub definition.
    At som
 @DirtiesContext
 public class LoanApplicationServiceTests {

    After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured -(or random) port.

    85.3.3 Server Side

    Since you are developing your stub, you need to be sure that it actually resembles your +(or random) port.

    81.3.3 Server Side

    Since you are developing your stub, you need to be sure that it actually resembles your concrete implementation. You cannot have a situation where your stub acts in one way and your application behaves in a different way, especially in production.

    To ensure that your application behaves the way you define in your stub, tests are generated from the stub you provide.

    The autogenerated test looks, more or less, like this:

    @Test
@@ -5914,7 +5838,7 @@ generated from the stub you provide.
    The autogenerated test looks, more or
         DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());
         assertThatJson(parsedJson).field("['fraudCheckStatus']").matches("[A-Z]{5}");
         assertThatJson(parsedJson).field("['rejection.reason']").isEqualTo("Amount too high");
-}

    85.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

    Consider an example of Fraud Detection and the Loan Issuance process. The business +}

    81.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

    Consider an example of Fraud Detection and the Loan Issuance process. The business scenario is such that we want to issue loans to people but do not want them to steal from us. The current implementation of our system grants loans to everybody.

    Assume that Loan Issuance is a client to the Fraud Detection server. In the current sprint, we must develop a new feature: if a client wants to borrow too much money, then @@ -5923,7 +5847,7 @@ Issuance has an artifact-id of http-client, and bot discuss changes while going through the process. CDC is all about communication.

    The server side code is available here and the client code here.

    [Tip]Tip

    In this case, the producer owns the contracts. Physically, all the contract are -in the producer’s repository.

    85.4.1 Technical note

    If using the SNAPSHOT / Milestone / Release Candidate versions please add the +in the producer’s repository.

    81.4.1 Technical note

    If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

    Maven.  

    <repositories>
 	<repository>
@@ -5985,7 +5909,7 @@ following section to your build:
    Maven. 
 	maven { url "http://repo.spring.io/milestone" }
 	maven { url "http://repo.spring.io/release" }
 }

    -

    85.4.2 Consumer side (Loan Issuance)

    As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

    1. Start doing TDD by writing a test for your feature.
    2. Write the missing implementation.
    3. Clone the Fraud Detection service repository locally.
    4. Define the contract locally in the repo of Fraud Detection service.
    5. Add the Spring Cloud Contract Verifier plugin.
    6. Run the integration tests.
    7. File a pull request.
    8. Create an initial implementation.
    9. Take over the pull request.
    10. Write the missing implementation.
    11. Deploy your app.
    12. Work online.

    Start doing TDD by writing a test for your feature.

    @Test
+

    81.4.2 Consumer side (Loan Issuance)

    As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

    1. Start doing TDD by writing a test for your feature.
    2. Write the missing implementation.
    3. Clone the Fraud Detection service repository locally.
    4. Define the contract locally in the repo of Fraud Detection service.
    5. Add the Spring Cloud Contract Verifier plugin.
    6. Run the integration tests.
    7. File a pull request.
    8. Create an initial implementation.
    9. Take over the pull request.
    10. Write the missing implementation.
    11. Deploy your app.
    12. Work online.

    Start doing TDD by writing a test for your feature.

    @Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
 	// given:
 	LoanApplication application = new LoanApplication(new Client("1234567890"),
@@ -6199,7 +6123,7 @@ with group id com.example, artifact id stubs classifier on port 8080.
    File a pull request.
    What you have done until now is an iterative process. You can play around with the
 contract, install it locally, and work on the consumer side until the contract works as
 you wish.
    Once you are satisfied with the results and the test passes, publish a pull request to
-the server side. Currently, the consumer side work is done.

    85.4.3 Producer side (Fraud Detection server)

    As a developer of the Fraud Detection server (a server to the Loan Issuance service):

    Create an initial implementation.

    As a reminder, you can see the initial implementation here:

    @RequestMapping(value = "/fraudcheck", method = PUT)
+the server side. Currently, the consumer side work is done.

    81.4.3 Producer side (Fraud Detection server)

    As a developer of the Fraud Detection server (a server to the Loan Issuance service):

    Create an initial implementation.

    As a reminder, you can see the initial implementation here:

    @RequestMapping(value = "/fraudcheck", method = PUT)
 public FraudCheckResult fraudCheck(@RequestBody FraudCheck fraudCheck) {
 return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
 }

    Take over the pull request.

    $ git checkout -b contract-change-pr master
@@ -6291,20 +6215,20 @@ Contract Verifier plugin adds the tests to the gene
 actually run those tests from your IDE.
    Deploy your app.
    Once you finish your work, you can deploy your change. First, merge the branch:
    $ git checkout master
 $ git merge --no-ff contract-change-pr
 $ git push origin master
    Your CI might run something like ./mvnw clean deploy, which would publish both the
-application and the stub artifacts.

    85.4.4 Consumer Side (Loan Issuance) Final Step

    As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

    Merge branch to master.

    $ git checkout master
+application and the stub artifacts.

    81.4.4 Consumer Side (Loan Issuance) Final Step

    As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

    Merge branch to master.

    $ git checkout master
 $ git merge --no-ff contract-change-pr

    Work online.

    Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can switch off the value of the workOffline parameter in your annotation. The following code shows an example of achieving the same thing by changing the properties.

    stubrunner:
   ids: 'com.example:http-server-dsl:+:stubs:8080'
-  repositoryRoot: http://repo.spring.io/libs-snapshot

    That’s it!

    85.5 Dependencies

    The best way to add dependencies is to use the proper starter dependency.

    For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add -spring-cloud-starter-contract-verifier.

    85.6 Additional Links

    Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note + repositoryRoot: http://repo.spring.io/libs-snapshot

    That’s it!

    81.5 Dependencies

    The best way to add dependencies is to use the proper starter dependency.

    For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add +spring-cloud-starter-contract-verifier.

    81.6 Additional Links

    Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under -constant development.

    85.6.1 Spring Cloud Contract video

    You can check out the video from the Warsaw JUG about Spring Cloud Contract:

    85.6.2 Readings

    85.7 Samples

    You can find some samples at -samples.

    86. Spring Cloud Contract FAQ

    86.1 Why use Spring Cloud Contract Verifier and not X ?

    For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating +constant development.

    81.6.1 Spring Cloud Contract video

    You can check out the video from the Warsaw JUG about Spring Cloud Contract:

    81.6.2 Readings

    81.7 Samples

    You can find some samples at +samples.

    82. Spring Cloud Contract FAQ

    82.1 Why use Spring Cloud Contract Verifier and not X ?

    For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make -Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

    • Possibility to do CDC with messaging
    • Clear and easy to use, statically typed DSL
    • Possibility to copy paste your current JSON file to the contract and only edit its elements
    • Automatic generation of tests from the defined Contract
    • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
    • Spring Cloud integration - no discovery service is needed for integration tests

    86.2 I don’t want to write a contract in Groovy!

    No problem. You can write a contract in YAML!

    86.3 What is this value(consumer(), producer()) ?

    One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. +Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

    • Possibility to do CDC with messaging
    • Clear and easy to use, statically typed DSL
    • Possibility to copy paste your current JSON file to the contract and only edit its elements
    • Automatic generation of tests from the defined Contract
    • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
    • Spring Cloud integration - no discovery service is needed for integration tests

    82.2 I don’t want to write a contract in Groovy!

    No problem. You can write a contract in YAML!

    82.3 What is this value(consumer(), producer()) ?

    One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. What typically makes that difficult are the hard-coded values of request / response elements. For example dates or ids. Imagine the following JSON request

    {
     "time" : "2016-10-10 20:10:15",
@@ -6370,19 +6294,19 @@ for time and UUID are simplified and most likely invalid but we want to keep thi
 					])
 			}
 }
    [Important]Important

    Please read the Groovy docs related to JSON to understand how to -properly structure the request / response bodies.

    86.4 How to do Stubs versioning?

    86.4.1 API Versioning

    Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are +properly structure the request / response bodies.

    82.4 How to do Stubs versioning?

    82.4.1 API Versioning

    Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

    • use Hypermedia, links and do not version your API by any means
    • pass versions through headers / urls

    I will not try to answer a question which approach is better. Whatever suit your needs and allows you to generate business value should be picked.

    Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. -You can create a subfolder for every version or append it to th contract name - whatever suits you more.

    86.4.2 JAR versioning

    If by versioning you mean the version of the JAR that contains the stubs then there are essentially two main approaches.

    Let’s assume that you’re doing Continuous Delivery / Deployment which means that you’re generating a new version of +You can create a subfolder for every version or append it to th contract name - whatever suits you more.

    82.4.2 JAR versioning

    If by versioning you mean the version of the JAR that contains the stubs then there are essentially two main approaches.

    Let’s assume that you’re doing Continuous Delivery / Deployment which means that you’re generating a new version of the jar each time you go through the pipeline and that jar can go to production at any time. For example your jar version looks like this (it got built on the 20.10.2016 at 20:15:21) :

    1.0.0.20161020-201521-RELEASE

    In that case your generated stub jar will look like this.

    1.0.0.20161020-201521-RELEASE-stubs.jar

    In this case you should inside your application.yml or @AutoConfigureStubRunner when referencing stubs provide the latest version of the stubs. You can do that by passing the + sign. Example

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

    If the versioning however is fixed (e.g. 1.0.4.RELEASE or 2.1.1) then you have to set the concrete value of the jar -version. Example for 2.1.1.

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})

    86.4.3 Dev or prod stubs

    You can manipulate the classifier to run the tests against current development version of the stubs of other services +version. Example for 2.1.1.

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})

    82.4.3 Dev or prod stubs

    You can manipulate the classifier to run the tests against current development version of the stubs of other services or the ones that were deployed to production. If you alter your build to deploy the stubs with the prod-stubs classifier - once you reach production deployment then you can run tests in one case with dev stubs and one with prod stubs.

    Example of tests using development version of stubs

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

    Example of tests using production version of stubs

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})

    You can pass those values also via properties from your deployment pipeline.

    86.5 Common repo with contracts

    Another way of storing contracts other than having them with the producer is keeping them in a common place. + once you reach production deployment then you can run tests in one case with dev stubs and one with prod stubs.

    Example of tests using development version of stubs

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

    Example of tests using production version of stubs

    @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})

    You can pass those values also via properties from your deployment pipeline.

    82.5 Common repo with contracts

    Another way of storing contracts other than having them with the producer is keeping them in a common place. It can be related to security issues where the consumers can’t clone the producer’s code. Also if you keep contracts in a single place then you, as a producer, will know how many consumers you have and which -consumer will you break with your local changes.

    86.5.1 Repo structure

    Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, +consumer will you break with your local changes.

    82.5.1 Repo structure

    Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup (which you can checkout here:

    ├── com
 │   └── example
@@ -6573,11 +6497,11 @@ Those poms are necessary for the consumer side to run mvn
 			</excludes>
 		</fileSet>
 	</fileSets>
-</assembly>

    86.5.2 Workflow

    The workflow would look similar to the one presented in the Step by step guide to CDC. The only difference +</assembly>

    82.5.2 Workflow

    The workflow would look similar to the one presented in the Step by step guide to CDC. The only difference is that the producer doesn’t own the contracts anymore. So the consumer and the producer have to work on - common contracts in a common repository.

    86.5.3 Consumer

    When the consumer wants to work on the contracts offline, instead of cloning the producer code, the + common contracts in a common repository.

    82.5.3 Consumer

    When the consumer wants to work on the contracts offline, instead of cloning the producer code, the consumer team clones the common repository, goes to the required producer’s folder (e.g. com/example/server) -and runs mvn clean install -DskipTests to install locally the stubs converted from the contracts.

    [Tip]Tip

    You need to have Maven installed locally

    86.5.4 Producer

    As a producer it’s enough to alter the Spring Cloud Contract Verifier to provide the URL and the dependency +and runs mvn clean install -DskipTests to install locally the stubs converted from the contracts.

    [Tip]Tip

    You need to have Maven installed locally

    82.5.4 Producer

    As a producer it’s enough to alter the Spring Cloud Contract Verifier to provide the URL and the dependency of the JAR containing the contracts:

    <plugin>
 	<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -6592,20 +6516,20 @@ of the JAR containing the contracts:
    http://link/to/your/nexus/or/artifactory/or/sth. It will be then unpacked in a local temporary folder
 and contracts present under the com/example/server will be picked as the ones used to generate the
 tests and the stubs. Due to this convention the producer team will know which consumer teams will be broken
-when some incompatible changes are done.
    The rest of the flow looks the same.

    86.6 Can I have multiple base classes for tests?

    Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins.

    86.7 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    86.7.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to +when some incompatible changes are done.

    The rest of the flow looks the same.

    82.6 Can I have multiple base classes for tests?

    Yes! Check out the Different base classes for contracts sections +of either Gradle or Maven plugins.

    82.7 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    82.7.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which -matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    86.7.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule +matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    82.7.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

    86.7.3 Can I reference the request from the response?

    Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support -for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

    86.7.4 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

    82.7.3 Can I reference the request from the response?

    Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support +for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

    82.7.4 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. -If you’re using YAML just use the bodyFromFile property.

    87. Spring Cloud Contract Verifier Setup

    You can set up Spring Cloud Contract Verifier in the following ways:

    87.1 Gradle Project

    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the -following sections:

    87.1.1 Prerequisites

    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a +If you’re using YAML just use the bodyFromFile property.

    83. Spring Cloud Contract Verifier Setup

    You can set up Spring Cloud Contract Verifier in the following ways:

    83.1 Gradle Project

    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the +following sections:

    83.1.1 Prerequisites

    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a Gradle or a Maven plugin.

    [Warning]Warning

    If you want to use Spock in your projects, you must add separately the spock-core and spock-spring modules. Check Spock -docs for more information

    87.1.2 Add Gradle Plugin with Dependencies

    To add a Gradle plugin with dependencies, use code similar to this:

    buildscript {
+docs for more information

    83.1.2 Add Gradle Plugin with Dependencies

    To add a Gradle plugin with dependencies, use code similar to this:

    buildscript {
 	repositories {
 		mavenCentral()
 	}
@@ -6630,7 +6554,7 @@ dependencies {
 	testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
 	testCompile 'org.spockframework:spock-spring:1.0-groovy-2.4'
 	testCompile 'org.springframework.cloud:spring-cloud-starter-contract-verifier'
-}

    87.1.3 Gradle and Rest Assured 2.0

    By default, Rest Assured 3.x is added to the classpath. However, to use Rest Assured 2.x +}

    83.1.3 Gradle and Rest Assured 2.0

    By default, Rest Assured 3.x is added to the classpath. However, to use Rest Assured 2.x you can add it to the plugins classpath, as shown here:

    buildscript {
 	repositories {
 		mavenCentral()
@@ -6649,7 +6573,7 @@ depenendencies {
     testCompile "com.jayway.restassured:rest-assured:2.5.0"
     testCompile "com.jayway.restassured:spring-mock-mvc:2.5.0"
 }

    That way, the plugin automatically sees that Rest Assured 2.x is present on the classpath -and modifies the imports accordingly.

    87.1.4 Snapshot Versions for Gradle

    Add the additional snapshot repository to your build.gradle to use snapshot versions, +and modifies the imports accordingly.

    83.1.4 Snapshot Versions for Gradle

    Add the additional snapshot repository to your build.gradle to use snapshot versions, which are automatically uploaded after every successful build, as shown here:

    buildscript {
 	repositories {
 		mavenCentral()
@@ -6658,16 +6582,16 @@ which are automatically uploaded after every successful build, as shown here:
    "http://repo.spring.io/milestone" }
 		maven { url "http://repo.spring.io/release" }
 	}
-}

    87.1.5 Add stubs

    By default, Spring Cloud Contract Verifier is looking for stubs in the +}

    83.1.5 Add stubs

    By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory.

    The directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test. Spring Cloud Contract Verifier assumes that it contains at least one level of directories that are to be used as the test class name. If more than one level of nested directories is present, all except the last one is used as the package name. For example, with following structure:

    src/test/resources/contracts/myservice/shouldCreateUser.groovy
 src/test/resources/contracts/myservice/shouldReturnUser.groovy

    Spring Cloud Contract Verifier creates a test class named defaultBasePackage.MyService -with two methods:

    • shouldCreateUser()
    • shouldReturnUser()

    87.1.6 Run the Plugin

    The plugin registers itself to be invoked before a check task. If you want it to be +with two methods:

    • shouldCreateUser()
    • shouldReturnUser()

    83.1.6 Run the Plugin

    The plugin registers itself to be invoked before a check task. If you want it to be part of your build process, you need to do nothing more. If you just want to generate -tests, invoke the generateContractTests task.

    87.1.7 Default Setup

    The default Gradle Plugin setup creates the following Gradle part of the build (in +tests, invoke the generateContractTests task.

    83.1.7 Default Setup

    The default Gradle Plugin setup creates the following Gradle part of the build (in pseudocode):

    contracts {
     targetFramework = 'JUNIT'
     testMode = 'MockMvc'
@@ -6711,12 +6635,12 @@ publishing {
             artifact verifierStubsJar
         }
     }
-}

    87.1.8 Configure Plugin

    To change the default configuration, add a contracts snippet to your Gradle config, as +}

    83.1.8 Configure Plugin

    To change the default configuration, add a contracts snippet to your Gradle config, as shown here:

    contracts {
 	testMode = 'MockMvc'
 	baseClassForTests = 'org.mycompany.tests'
 	generatedTestSourcesDir = project.file('src/generatedContract')
-}

    87.1.9 Configuration Options

    • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, +}

    83.1.9 Configuration Options

    • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, which is based on Spring’s MockMvc. It can also be changed to JaxRsClient or to Explicit for real HTTP calls.
    • imports: Creates an array with imports that should be included in generated tests (for example ['org.myorg.Matchers']). By default, it creates an empty array.
    • staticImports: Creates an array with static imports that should be included in @@ -6744,7 +6668,7 @@ closure to set it up. separated. Otherwise, it scans contracts under the provided directory. * contractsWorkOffline: Specifies whether to download the dependencies each time, so that you can work online. In other words, it specifies whether to reuses the local Maven -repo.

    87.1.10 Single Base Class for All Tests

    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base +repo.

    83.1.10 Single Base Class for All Tests

    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base specification for all generated acceptance tests. In this class, you need to point to an endpoint, which should be verified.

    abstract class BaseMockMvcSpec extends Specification {
 
@@ -6763,7 +6687,7 @@ endpoint, which should be verified.
    If you use Explicit mode, you can use a base class to initialize the whole tested app
 as you might see in regular integration tests. If you use the JAXRSCLIENT mode, this
 base class should also contain a protected WebTarget webTarget field. Right now, the
-only option to test the JAX-RS API is to start a web server.

    87.1.11 Different Base Classes for Contracts

    If your base classes differ between contracts, you can tell the Spring Cloud Contract +only option to test the JAX-RS API is to start a web server.

    83.1.11 Different Base Classes for Contracts

    If your base classes differ between contracts, you can tell the Spring Cloud Contract plugin which class should get extended by the autogenerated tests. You have two options:

    • Follow a convention by providing the packageWithBaseClasses
    • Provide explicit mapping via baseClassMappings

    By Convention

    The convention is such that if you have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set the value of the packageWithBaseClasses property to com.example.base, then Spring Cloud Contract @@ -6782,7 +6706,7 @@ baseClassMappings { - src/test/resources/contract/foo/

    By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You could also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    87.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    87.1.13 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    83.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    83.1.13 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you do not want to use Stub Runner then you need to copy contracts stored in src/test/resources/contracts and generate WireMock JSON stubs using:

    ./gradlew generateClientStubs
    [Note]Note

    The stubsOutputDir option has to be set for stub generation to work.

    When present, JSON stubs can be used in automated tests of consuming a service.

    @ContextConfiguration(loader == SpringApplicationContextLoader, classes == Application)
@@ -6806,8 +6730,8 @@ WireMock JSON stubs using:
    ./gradlew generateClie
 	loanApplication.rejectionReason == null
  }
 }
    LoanApplication makes a call to FraudDetection service. This request is handled by a
-WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

    87.2 Maven Project

    To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the -following sections:

    87.2.1 Add maven plugin

    Add the Spring Cloud Contract BOM in a fashion similar to this:

    <dependencyManagement>
+WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

    83.2 Maven Project

    To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the +following sections:

    83.2.1 Add maven plugin

    Add the Spring Cloud Contract BOM in a fashion similar to this:

    <dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -6827,7 +6751,7 @@ following sections:
      </configuration>
 </plugin>

    You can read more in the Spring -Cloud Contract Maven Plugin Documentation.

    87.2.2 Maven and Rest Assured 2.0

    By default, Rest Assured 3.x is added to the classpath. However, you can use Rest +Cloud Contract Maven Plugin Documentation.

    83.2.2 Maven and Rest Assured 2.0

    By default, Rest Assured 3.x is added to the classpath. However, you can use Rest Assured 2.x by adding it to the plugins classpath, as shown here:

    <plugin>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -6873,7 +6797,7 @@ Assured 2.x by adding it to the plugins classpath, as shown here:
    That way, the plugin automatically sees that Rest Assured 3.x is present on the classpath
-and modifies the imports accordingly.

    87.2.3 Snapshot versions for Maven

    For Snapshot and Milestone versions, you have to add the following section to your +and modifies the imports accordingly.

    83.2.3 Snapshot versions for Maven

    For Snapshot and Milestone versions, you have to add the following section to your pom.xml, as shown here:

    <repositories>
 	<repository>
 		<id>spring-snapshots</id>
@@ -6925,16 +6849,16 @@ and modifies the imports accordingly.
    <enabled>false</enabled> </snapshots> </pluginRepository> -</pluginRepositories>

    87.2.4 Add stubs

    By default, Spring Cloud Contract Verifier is looking for stubs in the +</pluginRepositories>

    83.2.4 Add stubs

    By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory. The directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test. We assume that it contains at least one directory to be used as test class name. If there is more than one level of nested directories, all except the last one is used as package name. For example, with following structure:

    src/test/resources/contracts/myservice/shouldCreateUser.groovy
 src/test/resources/contracts/myservice/shouldReturnUser.groovy

    Spring Cloud Contract Verifier creates a test class named defaultBasePackage.MyService -with two methods

    • shouldCreateUser()
    • shouldReturnUser()

    87.2.5 Run plugin

    The plugin goal generateTests is assigned to be invoked in the phase called +with two methods

    • shouldCreateUser()
    • shouldReturnUser()

    83.2.5 Run plugin

    The plugin goal generateTests is assigned to be invoked in the phase called generate-test-sources. If you want it to be part of your build process, you need not do -anything. If you just want to generate tests, invoke the generateTests goal.

    87.2.6 Configure plugin

    To change the default configuration, just add a configuration section to the plugin +anything. If you just want to generate tests, invoke the generateTests goal.

    83.2.6 Configure plugin

    To change the default configuration, just add a configuration section to the plugin definition or the execution definition, as shown here:

    <plugin>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -6951,7 +6875,7 @@ definition or the execution definition, as shown he
         <basePackageForTests>org.springframework.cloud.verifier.twitter.place</basePackageForTests>
         <baseClassForTests>org.springframework.cloud.verifier.twitter.place.BaseMockMvcSpec</baseClassForTests>
     </configuration>
-</plugin>

    87.2.7 Configuration Options

    • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, +</plugin>

    83.2.7 Configuration Options

    • testMode: Defines the mode for acceptance tests. By default, the mode is MockMvc, which is based on Spring’s MockMvc. It can also be changed to JaxRsClient or to Explicit for real HTTP calls.
    • basePackageForTests: Specifies the base package for all generated tests. If not set, the value is picked from baseClassForTests’s package and from `packageWithBaseClasses. @@ -6978,7 +6902,7 @@ the following options:

        groupid/artifactid where gropuid is slash separated.
      • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the local Maven artifacts should be reused.
      • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided, use the current Maven ones.
      • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
      • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
      • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
      • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.

      We cache only non-snapshot, explicitly provided versions (for example -+ or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

    87.2.8 Single Base Class for All Tests

    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base ++ or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

    83.2.8 Single Base Class for All Tests

    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base specification for all generated acceptance tests. In this class, you need to point to an endpoint, which should be verified.

    package org.mycompany.tests
 
@@ -6993,7 +6917,7 @@ endpoint, which should be verified.
    If you use Explicit mode, you can use a base class to initialize the whole tested app
 similarly, as you might find in regular integration tests. If you use the JAXRSCLIENT
 mode, this base class should also contain a protected WebTarget webTarget field. Right
-now, the only option to test the JAX-RS API is to start a web server.

    87.2.9 Different base classes for contracts

    If your base classes differ between contracts, you can tell the Spring Cloud Contract +now, the only option to test the JAX-RS API is to start a web server.

    83.2.9 Different base classes for contracts

    If your base classes differ between contracts, you can tell the Spring Cloud Contract plugin which class should get extended by the autogenerated tests. You have two options:

    • Follow a convention by providing the packageWithBaseClasses
    • provide explicit mapping via baseClassMappings

    By Convention

    The convention is such that if you have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set the value of the packageWithBaseClasses property to com.example.base, then Spring Cloud Contract @@ -7026,7 +6950,7 @@ name of the base class for the matched contract. You have to provide a list call * src/test/resources/contract/foo/

    By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You can also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    87.2.10 Invoking generated tests

    The Spring Cloud Contract Maven Plugin generates verification code in a directory called +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    83.2.10 Invoking generated tests

    The Spring Cloud Contract Maven Plugin generates verification code in a directory called /generated-test-sources/contractVerifier and attaches this directory to testCompile goal.

    For Groovy Spock code, use the following:

    <plugin>
 	<groupId>org.codehaus.gmavenplus</groupId>
@@ -7056,7 +6980,7 @@ goal.
    For Groovy Spock code, use the following:
    </testSources>
 	</configuration>
 </plugin>
    To ensure that provider side is compliant with defined contracts, you need to invoke
-mvn generateTest test.

    87.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+mvn generateTest test.

    83.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
@@ -7093,7 +7017,7 @@ goal.
    For Groovy Spock code, use the following:
    </plugin>
         </plugins>
     </pluginManagement>
-</build>

    87.3 Stubs and Transitive Dependencies

    The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One +</build>

    83.3 Stubs and Transitive Dependencies

    The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One problem that arises is that, when reusing the stubs, you can mistakenly import all of that stub’s dependencies. When building a Maven artifact, even though you have a couple of different jars, all of them share one pom:

    ├── github-webhook-0.0.1.BUILD-20160903.075506-1-stubs.jar
@@ -7110,14 +7034,14 @@ when you include the github-webhook stubs in anothe
 dependency gets downloaded by Stub Runner) then, since all of the dependencies are
 optional, they will not get downloaded.
    Create a separate artifactid for the stubs
    If you create a separate artifactid, then you can set it up in whatever way you wish.
 For example, you might decide to have no dependencies at all.
    Exclude dependencies on the consumer side
    As a consumer, if you add the stub dependency to your classpath, you can explicitly
-exclude the unwanted dependencies.

    87.4 CI Server setup

    When fetching stubs / contracts in a CI, shared environment, what might happen is that +exclude the unwanted dependencies.

    83.4 CI Server setup

    When fetching stubs / contracts in a CI, shared environment, what might happen is that both the producer and the consumer reuse the same local Maven repository. Due to this, the framework, responsible for downloading a stub JAR from remote location, can’t decide which JAR should be picked, local or remote one. That caused the "The artifact was found in the local repository but you have explicitly stated that it should be downloaded from a remote one" exception and failed the build.

    For such cases we’re introducing the property mechanism:

    • via stubrunner.snapshot-check-skip system property
    • via STUBRUNNER_SNAPSHOT_CHECK_SKIP environment variable

    if either of these values is set to true, then the stub downloader will not -verify the origin of the downloaded JAR.

    87.5 Scenarios

    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to +verify the origin of the downloaded JAR.

    83.5 Scenarios

    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to stick to the proper naming convention while creating your contracts. The convention requires including an order number followed by an underscore. This will work regardles of whether you’re working with YAML or Groovy. Example:

    my_contracts_dir\
@@ -7126,10 +7050,10 @@ requires including an order number followed by an underscore. This will work reg
     2_showCart.groovy
     3_logout.groovy

    Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

    1. login marked as Started pointing to…​
    2. showCart marked as Step1 pointing to…​
    3. logout marked as Step2 which will close the scenario.

    More details about WireMock scenarios can be found at -http://wiremock.org/stateful-behaviour.html

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    87.6 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image +http://wiremock.org/stateful-behaviour.html

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    83.6 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

    [Tip]Tip

    The EXPLICIT mode means that the tests generated from contracts will send -real requests and not the mocked ones.

    87.6.1 Short intro to Maven, JARs and Binary storage

    Since the Docker image can be used by non JVM projects, it’s good to +real requests and not the mocked ones.

    83.6.1 Short intro to Maven, JARs and Binary storage

    Since the Docker image can be used by non JVM projects, it’s good to explain the basic terms behind Spring Cloud Contract packaging defaults.

    Part of the following definitions were taken from the Maven Glossary

    • Project: Maven thinks in terms of projects. Everything that you will build are projects. Those projects follow a well defined “Project Object Model”. Projects can depend on other projects, @@ -7156,7 +7080,7 @@ like them to be available for others to download / reference or reuse. In case of the JVM world those artifacts would be JARs, for Ruby these are gems and for Docker those would be Docker images. You can store those artifacts in a manager. Examples of such managers can be Artifactory -or Nexus.

    87.6.2 How it works

    The image searches for contracts under the /contracts folder. +or Nexus.

    83.6.2 How it works

    The image searches for contracts under the /contracts folder. The output from running the tests will be available under /spring-cloud-contract/build folder (it’s useful for debugging purposes).

    It’s enough for you to mount your contracts, pass the environment variables @@ -7171,8 +7095,8 @@ for group id foo.bar and artifact id .m2. Mount your local .m2 as a volume available at the container’s /root/.m2 path. You must not set both EXTERNAL_CONTRACTS_WORK_OFFLINE and EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL.

    These environment variables are used when tests are executed:

    • APPLICATION_BASE_URL - url against which tests should be executed. Remember that it has to be accessible from the Docker container (e.g. localhost -will not work)
    • APPLICATION_USERNAME - (optional) username for basic authentication to your application
    • APPLICATION_PASSWORD - (optional) password for basic authentication to your application

    87.6.3 Example of usage

    Let’s take a look at a simple MVC application

    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
-$ cd bookstore

    The contracts are available under /contracts folder.

    87.6.4 Server side (nodejs)

    Since we want to run tests, we could just execute:

    $ npm test

    however, for learning purposes, let’s split it into pieces:

    # Stop docker infra (nodejs, artifactory)
+will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application

    • 83.6.3 Example of usage

    Let’s take a look at a simple MVC application

    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
+$ cd bookstore

    The contracts are available under /contracts folder.

    83.6.4 Server side (nodejs)

    Since we want to run tests, we could just execute:

    $ npm test

    however, for learning purposes, let’s split it into pieces:

    # Stop docker infra (nodejs, artifactory)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
@@ -7204,9 +7128,9 @@ stateful situation
      • the contracts will be taken from /contracts folder.
      • the output of the test execution is available under
 node_modules/spring-cloud-contract/output.
  • the stubs will be uploaded to Artifactory. You can check them out
 under http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/ .
-The stubs will be here http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/bookstore-0.0.1.RELEASE-stubs.jar.

    • To see how the client side looks like check out the Section 89.9, “Stub Runner Docker” section.

    88. Spring Cloud Contract Verifier Messaging

    Spring Cloud Contract Verifier lets you verify applications that uses messaging as a +The stubs will be here http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/bookstore-0.0.1.RELEASE-stubs.jar.

    To see how the client side looks like check out the Section 85.9, “Stub Runner Docker” section.

    84. Spring Cloud Contract Verifier Messaging

    Spring Cloud Contract Verifier lets you verify applications that uses messaging as a means of communication. All of the integrations shown in this document work with Spring, -but you can also create one of your own and use that.

    88.1 Integrations

    You can use one of the following four integration configurations:

    • Apache Camel
    • Spring Integration
    • Spring Cloud Stream
    • Spring AMQP

    Since we use Spring Boot, if you have added one of these libraries to the classpath, all +but you can also create one of your own and use that.

    84.1 Integrations

    You can use one of the following four integration configurations:

    • Apache Camel
    • Spring Integration
    • Spring Cloud Stream
    • Spring AMQP

    Since we use Spring Boot, if you have added one of these libraries to the classpath, all the messaging configuration is automatically set up.

    [Important]Important

    Remember to put @AutoConfigureMessageVerifier on the base class of your generated tests. Otherwise, messaging part of Spring Cloud Contract Verifier does not work.

    [Important]Important

    If you want to use Spring Cloud Stream, remember to add a dependency on @@ -7218,7 +7142,7 @@ work.

    </dependency>

    Gradle.  

    testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

    -

    88.2 Manual Integration Testing

    The main interface used by the tests is +

    84.2 Manual Integration Testing

    The main interface used by the tests is org.springframework.cloud.contract.verifier.messaging.MessageVerifier. It defines how to send and receive messages. You can create your own implementation to achieve the same goal.

    In a test, you can inject a ContractVerifierMessageExchange to send and receive @@ -7232,14 +7156,14 @@ Here’s an example:

    private MessageVerifier verifier;
   ...
 }
    [Note]Note

    If your tests require stubs as well, then @AutoConfigureStubRunner includes the -messaging configuration, so you only need the one annotation.

    88.3 Publisher-Side Test Generation

    Having the input or outputMessage sections in your DSL results in creation of tests +messaging configuration, so you only need the one annotation.

    84.3 Publisher-Side Test Generation

    Having the input or outputMessage sections in your DSL results in creation of tests on the publisher’s side. By default, JUnit tests are created. However, there is also a possibility to create Spock tests.

    There are 3 main scenarios that we should take into consideration:

    • Scenario 1: There is no input message that produces an output message. The output message is triggered by a component inside the application (for example, scheduler).
    • Scenario 2: The input message triggers an output message.
    • Scenario 3: The input message is consumed and there is no output message.
    [Important]Important

    The destination passed to messageFrom or sentTo can have different meanings for different messaging implementations. For Stream and Integration it is first resolved as a destination of a channel. Then, if there is no such destination it is resolved as a channel name. For Camel, that’s a certain component (for example, -jms).

    88.3.1 Scenario 1: No Input Message

    Here is an example for Camel. For the given contract:

    Groovy DSL.  +jms).

    84.3.1 Scenario 1: No Input Message

    Here is an example for Camel. For the given contract:

    Groovy DSL.  

    def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -7292,7 +7216,7 @@ outputMessage:
   DocumentContext parsedJson = JsonPath.parse(contractVerifierObjectMapper.writeValueAsString(response.payload))
   assertThatJson(parsedJson).field("bookName").isEqualTo("foo")
 
-'''

    88.3.2 Scenario 2: Output Triggered by Input

    Here is an example for Camel. For the given contract:

    Groovy DSL.  +'''

    84.3.2 Scenario 2: Output Triggered by Input

    Here is an example for Camel. For the given contract:

    Groovy DSL.  

    def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -7363,7 +7287,7 @@ then:
 and:
    DocumentContext parsedJson = JsonPath.parse(contractVerifierObjectMapper.writeValueAsString(response.payload))
    assertThatJson(parsedJson).field("bookName").isEqualTo("foo")
-"""

    88.3.3 Scenario 3: No Output Message

    Here is an example for Camel. For the given contract:

    Groovy DSL.  +"""

    84.3.3 Scenario 3: No Output Message

    Here is an example for Camel. For the given contract:

    Groovy DSL.  

    def contractDsl = Contract.make {
 	label 'some_label'
 	input {
@@ -7411,7 +7335,7 @@ when:
 then:
 	 noExceptionThrown()
 	 bookWasDeleted()
-'''

    88.4 Consumer Stub Generation

    Unlike the HTTP part, in messaging, we need to publish the Groovy DSL inside the JAR with +'''

    84.4 Consumer Stub Generation

    Unlike the HTTP part, in messaging, we need to publish the Groovy DSL inside the JAR with a stub. Then it is parsed on the consumer side and proper stubbed routes are created.

    For more information, see the Stub Runner Messaging sections.

    Maven.  @@ -7463,11 +7387,11 @@ publishing { } } }

    -

    89. Spring Cloud Contract Stub Runner

    One of the issues that you might encounter while using Spring Cloud Contract Verifier is +

    85. Spring Cloud Contract Stub Runner

    One of the issues that you might encounter while using Spring Cloud Contract Verifier is passing the generated WireMock JSON stubs from the server side to the client side (or to various clients). The same takes place in terms of client-side generation for messaging.

    Copying the JSON files and setting the client side for messaging manually is out of the question. That is why we introduced Spring Cloud Contract Stub Runner. It can -automatically download and run the stubs for you.

    89.1 Snapshot versions

    Add the additional snapshot repository to your build.gradle file to use snapshot +automatically download and run the stubs for you.

    85.1 Snapshot versions

    Add the additional snapshot repository to your build.gradle file to use snapshot versions, which are automatically uploaded after every successful build:

    Maven.  

    <repositories>
 	<repository>
@@ -7530,7 +7454,7 @@ versions, which are automatically uploaded after every successful build:
    "http://repo.spring.io/milestone" }
 		maven { url "http://repo.spring.io/release" }
 	}

    -

    89.2 Publishing Stubs as JARs

    The easiest approach would be to centralize the way stubs are kept. For example, you can +

    85.2 Publishing Stubs as JARs

    The easiest approach would be to centralize the way stubs are kept. For example, you can keep them as jars in a Maven repository.

    [Tip]Tip

    For both Maven and Gradle, the setup comes ready to work. However, you can customize it if you want to.

    Maven.  

    <!-- First disable the default jar setup in the properties section -->
@@ -7618,9 +7542,9 @@ publishing {
 		}
 	}
 }

    -

    89.3 Stub Runner Core

    Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of +

    85.3 Stub Runner Core

    Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of Consumer Driven Contracts.

    Stub Runner allows you to automatically download the stubs of the provided dependencies (or pick those from the classpath), start WireMock servers for them and feed them with proper stub definitions. -For messaging, special stub routes are defined.

    89.3.1 Retrieving stubs

    You can pick the following options of acquiring stubs

    • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
    • Classpath scanning solution that searches classpath via pattern to retrieve stubs
    • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

    The latter example is described in the Custom Stub Runner section.

    Stub downloading

    If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set +For messaging, special stub routes are defined.

    85.3.1 Retrieving stubs

    You can pick the following options of acquiring stubs

    • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
    • Classpath scanning solution that searches classpath via pattern to retrieve stubs
    • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

    The latter example is described in the Custom Stub Runner section.

    Stub downloading

    If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set to true then Stub Runner will connect to the given server and download the required jars. It will then unpack the JAR to a temporary folder and reference those files in further contract processing.

    Example:

    @AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095")

    Classpath scanning

    If you DON’T provide the stubrunner.repositoryRoot and stubrunner.workOffline flag will @@ -7681,7 +7605,7 @@ structure in your stubs jar.

    └──
                 │       └── contract2.groovy
                 └── mappings
                     └── mapping.json

    By maintaining this structure classpath gets scanned and you can profit from the messaging / -HTTP stubs without the need to download artifacts.

    89.3.2 Running stubs

    Limitations

    [Important]Important

    There might be a problem with StubRunner shutting down ports between tests. You might +HTTP stubs without the need to download artifacts.

    85.3.2 Running stubs

    Limitations

    [Important]Important

    There might be a problem with StubRunner shutting down ports between tests. You might have a situation in which you get port conflicts. As long as you use the same context across tests everything works fine. But when the context are different (e.g. different stubs or different profiles) then you have to either use @DirtiesContext to shut down the stub servers, or else run them on @@ -7748,7 +7672,7 @@ mappings available for the given server:

    ["uuid" : "f9152eb9-bf77-4c38-8289-90be7d10d0d7"
 },
 ...
-]

    Messaging Stubs

    Depending on the provided Stub Runner dependency and the DSL the messaging routes are automatically set up.

    89.4 Stub Runner JUnit Rule

    Stub Runner comes with a JUnit rule thanks to which you can very easily download and run stubs for given group and artifact id:

    @ClassRule public static StubRunnerRule rule = new StubRunnerRule()
+]

    Messaging Stubs

    Depending on the provided Stub Runner dependency and the DSL the messaging routes are automatically set up.

    85.4 Stub Runner JUnit Rule

    Stub Runner comes with a JUnit rule thanks to which you can very easily download and run stubs for given group and artifact id:

    @ClassRule public static StubRunnerRule rule = new StubRunnerRule()
 		.repoRoot(repoRoot())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer");

    After that rule gets executed Stub Runner connects to your Maven repository and for the given list of dependencies tries to:

    • download them
    • cache them locally
    • unzip them to a temporary folder
    • start a WireMock server for each Maven dependency on a random port from the provided range of ports / provided port
    • feed the WireMock server with all JSON files that are valid WireMock definitions
    • can also send messages (remember to pass an implementation of MessageVerifier interface)

    Stub Runner uses Eclipse Aether mechanism to download the Maven dependencies. @@ -7831,14 +7755,14 @@ def 'should outp then(httpGet(rule.findStubUrl("fraudDetectionServer").toString() + "/name")).isEqualTo("fraudDetectionServer"); }

    Check the Common properties for JUnit and Spring for more information on how to apply global configuration of Stub Runner.

    [Important]Important

    To use the JUnit rule together with messaging you have to provide an implementation of the MessageVerifier interface to the rule builder (e.g. rule.messageVerifier(new MyMessageVerifier())). -If you don’t do this then whenever you try to send a message an exception will be thrown.

    89.4.1 Maven settings

    The stub downloader honors Maven settings for a different local repository folder. -Authentication details for repositories and profiles are currently not taken into account, so you need to specify it using the properties mentioned above.

    89.4.2 Providing fixed ports

    You can also run your stubs on fixed ports. You can do it in two different ways. One is to pass it in the properties, and the other via fluent API of -JUnit rule.

    89.4.3 Fluent API

    When using the StubRunnerRule you can add a stub to download and then pass the port for the last downloaded stub.

    @ClassRule public static StubRunnerRule rule = new StubRunnerRule()
+If you don’t do this then whenever you try to send a message an exception will be thrown.

    85.4.1 Maven settings

    The stub downloader honors Maven settings for a different local repository folder. +Authentication details for repositories and profiles are currently not taken into account, so you need to specify it using the properties mentioned above.

    85.4.2 Providing fixed ports

    You can also run your stubs on fixed ports. You can do it in two different ways. One is to pass it in the properties, and the other via fluent API of +JUnit rule.

    85.4.3 Fluent API

    When using the StubRunnerRule you can add a stub to download and then pass the port for the last downloaded stub.

    @ClassRule public static StubRunnerRule rule = new StubRunnerRule()
 		.repoRoot(repoRoot())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.withPort(12345)
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer:12346");

    You can see that for this example the following test is valid:

    then(rule.findStubUrl("loanIssuance")).isEqualTo(URI.create("http://localhost:12345").toURL());
-then(rule.findStubUrl("fraudDetectionServer")).isEqualTo(URI.create("http://localhost:12346").toURL());

    89.4.4 Stub Runner with Spring

    Sets up Spring configuration of the Stub Runner project.

    By providing a list of stubs inside your configuration file the Stub Runner automatically downloads +then(rule.findStubUrl("fraudDetectionServer")).isEqualTo(URI.create("http://localhost:12346").toURL());

    85.4.4 Stub Runner with Spring

    Sets up Spring configuration of the Stub Runner project.

    By providing a list of stubs inside your configuration file the Stub Runner automatically downloads and registers in WireMock the selected stubs.

    If you want to find the URL of your stubbed dependency you can autowire the StubFinder interface and use its methods as presented below:

    @ContextConfiguration(classes = Config, loader = SpringBootContextLoader)
 @SpringBootTest(properties = [" stubrunner.cloud.enabled=false",
@@ -7928,7 +7852,7 @@ Below you can find an example of achieving the same result by setting values on
 		"org.springframework.cloud.contract.verifier.stubs:bootService"],
 		repositoryRoot = "classpath:m2repo/repository/")

    Stub Runner Spring registers environment variables in the following manner for every registered WireMock server. Example for Stub Runner ids - com.example:foo, com.example:bar.

    • stubrunner.runningstubs.foo.port
    • stubrunner.runningstubs.bar.port

    Which you can reference in your code.

    89.5 Stub Runner Spring Cloud

    Stub Runner can integrate with Spring Cloud.

    For real life examples you can check the

    89.5.1 Stubbing Service Discovery

    The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

    • DiscoveryClient
    • Ribbon ServerList

    that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. + com.example:foo, com.example:bar.

    • stubrunner.runningstubs.foo.port
    • stubrunner.runningstubs.bar.port

    Which you can reference in your code.

    85.5 Stub Runner Spring Cloud

    Stub Runner can integrate with Spring Cloud.

    For real life examples you can check the

    85.5.1 Stubbing Service Discovery

    The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

    • DiscoveryClient
    • Ribbon ServerList

    that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using Feign, load balanced RestTemplate or DiscoveryClient directly, to call those stubbed servers instead of calling the real Service Discovery tool.

    For example this test will pass

    def 'should make service discovery work'() {
 	expect: 'WireMocks are running'
@@ -7947,16 +7871,16 @@ via a static block like presented below (example for Eureka)
    static {
         System.setProperty("eureka.client.enabled", "false");
         System.setProperty("spring.cloud.config.failFast", "false");
-    }

    89.5.2 Additional Configuration

    You can match the artifactId of the stub with the name of your app by using the stubrunner.idsToServiceIds: map. + }

    85.5.2 Additional Configuration

    You can match the artifactId of the stub with the name of your app by using the stubrunner.idsToServiceIds: map. You can disable Stub Runner Ribbon support by providing: stubrunner.cloud.ribbon.enabled equal to false You can disable Stub Runner support by providing: stubrunner.cloud.enabled equal to false

    [Tip]Tip

    By default all service discovery will be stubbed. That means that regardless of the fact if you have an existing DiscoveryClient its results will be ignored. However, if you want to reuse it, just set stubrunner.cloud.delegate.enabled to true and then your existing DiscoveryClient results will be merged with the stubbed ones.

    The default Maven configuration used by Stub Runner can be tweaked either -via the following system properties or environment variables

    • maven.repo.local - path to the custom maven local repository location
    • org.apache.maven.user-settings - path to custom maven user settings location
    • org.apache.maven.global-settings - path to maven global settings location

    89.6 Stub Runner Boot Application

    Spring Cloud Contract Stub Runner Boot is a Spring Boot application that exposes REST endpoints to +via the following system properties or environment variables

    • maven.repo.local - path to the custom maven local repository location
    • org.apache.maven.user-settings - path to custom maven user settings location
    • org.apache.maven.global-settings - path to maven global settings location

    85.6 Stub Runner Boot Application

    Spring Cloud Contract Stub Runner Boot is a Spring Boot application that exposes REST endpoints to trigger the messaging labels and to access started WireMock servers.

    One of the use-cases is to run some smoke (end to end) tests on a deployed application. You can check out the Spring Cloud Pipelines -project for more information.

    89.6.1 How to use it?

    Stub Runner Server

    Just add the

    compile "org.springframework.cloud:spring-cloud-starter-stub-runner"

    Annotate a class with @EnableStubRunnerServer, build a fat-jar and you’re ready to go!

    For the properties check the Stub Runner Spring section.

    Stub Runner Server Fat Jar

    You can download a standalone JAR from Maven (for example, for version 1.2.3.RELEASE), as follows:

    $ wget -O stub-runner.jar 'https://search.maven.org/remote_content?g=org.springframework.cloud&a=spring-cloud-contract-stub-runner-boot&v=1.2.3.RELEASE'
+project for more information.
    85.6.1 How to use it?
    Stub Runner Server
    Just add the
    compile "org.springframework.cloud:spring-cloud-starter-stub-runner"
    Annotate a class with @EnableStubRunnerServer, build a fat-jar and you’re ready to go!
    For the properties check the Stub Runner Spring section.
    Stub Runner Server Fat Jar
    You can download a standalone JAR from Maven (for example, for version 1.2.3.RELEASE), as follows:
    $ wget -O stub-runner.jar 'https://search.maven.org/remote_content?g=org.springframework.cloud&a=spring-cloud-contract-stub-runner-boot&v=1.2.3.RELEASE'
 $ java -jar stub-runner.jar --stubrunner.ids=... --stubrunner.repositoryRoot=...
    Spring Cloud CLI
    Starting from 1.4.0.RELEASE version of the Spring Cloud CLI
 project you can start Stub Runner Boot by executing spring cloud stubrunner.
    In order to pass the configuration just create a stubrunner.yml file in the current working directory
 or a subdirectory called config or in ~/.spring-cloud. The file could look like this
@@ -7966,7 +7890,7 @@ or a subdirectory called config or in spring cloud stubrunner from your terminal window to start
-the Stub Runner server. It will be available at port 8750.
    89.6.2 Endpoints
    HTTP
    • GET /stubs - returns a list of all running stubs in ivy:integer notation
    • GET /stubs/{ivy} - returns a port for the given ivy notation (when calling the endpoint ivy can also be artifactId only)
    Messaging
    For Messaging
    • GET /triggers - returns a list of all running labels in ivy : [ label1, label2 …​] notation
    • POST /triggers/{label} - executes a trigger with label
    • POST /triggers/{ivy}/{label} - executes a trigger with label for the given ivy notation (when calling the endpoint ivy can also be artifactId only)
    89.6.3 Example
    @ContextConfiguration(classes = StubRunnerBoot, loader = SpringBootContextLoader)
+the Stub Runner server. It will be available at port 8750.

    85.6.2 Endpoints

    HTTP

    • GET /stubs - returns a list of all running stubs in ivy:integer notation
    • GET /stubs/{ivy} - returns a port for the given ivy notation (when calling the endpoint ivy can also be artifactId only)

    Messaging

    For Messaging

    • GET /triggers - returns a list of all running labels in ivy : [ label1, label2 …​] notation
    • POST /triggers/{label} - executes a trigger with label
    • POST /triggers/{ivy}/{label} - executes a trigger with label for the given ivy notation (when calling the endpoint ivy can also be artifactId only)

    85.6.3 Example

    @ContextConfiguration(classes = StubRunnerBoot, loader = SpringBootContextLoader)
 @SpringBootTest(properties = "spring.cloud.zookeeper.enabled=false")
 @ActiveProfiles("test")
 class StubRunnerBootSpec extends Specification {
@@ -8052,7 +7976,7 @@ the Stub Runner server. It will be available at port 8750<
 			e.message.contains("org.springframework.cloud.contract.verifier.stubs:bootService:0.0.1-SNAPSHOT:stubs=")
 	}
 
-}

    89.6.4 Stub Runner Boot with Service Discovery

    One of the possibilities of using Stub Runner Boot is to use it as a feed of stubs for "smoke-tests". What does it mean? +}

    85.6.4 Stub Runner Boot with Service Discovery

    One of the possibilities of using Stub Runner Boot is to use it as a feed of stubs for "smoke-tests". What does it mean? Let’s assume that you don’t want to deploy 50 microservice to a test environment in order to check if your application is working fine. You’ve already executed a suite of tests during the build process but you would also like to ensure that the packaging of your application is fine. What you can do @@ -8085,7 +8009,7 @@ and we want to have the stub runner feature turned on @Aut (4) - we provide a list of artifactId to serviceId mapping

    That way your deployed application can send requests to started WireMock servers via the service discovery. Most likely points 1-3 could be set by default in application.yml cause they are not likely to change. That way you can provide only the list of stubs to download whenever you start -the Stub Runner Boot.

    89.7 Stubs Per Consumer

    There are cases in which 2 consumers of the same endpoint want to have 2 different responses.

    [Tip]Tip

    This approach also allows you to immediately know which consumer is using which part of your API. +the Stub Runner Boot.

    85.7 Stubs Per Consumer

    There are cases in which 2 consumers of the same endpoint want to have 2 different responses.

    [Tip]Tip

    This approach also allows you to immediately know which consumer is using which part of your API. You can remove part of a response that your API produces and you can see which of your autogenerated tests fails. If none fails then you can safely delete that part of the response cause nobody is using it.

    Let’s look at the following example for contract defined for the producer called producer. There are 2 consumers: foo-consumer and bar-consumer.

    Consumer foo-service

    request {
@@ -8138,26 +8062,26 @@ Or set the test as follows:
    foo-consumer in its name (i.e. those from the
 src/test/resources/contracts/foo-consumer/some/contracts/…​ folder) will be allowed to be referenced.
    You can check out issue 224 for more
-information about the reasons behind this change.

    89.8 Common

    This section briefly describes common properties, including:

    89.8.1 Common Properties for JUnit and Spring

    You can set repetitive properties by using system properties or Spring configuration +information about the reasons behind this change.

    85.8 Common

    This section briefly describes common properties, including:

    85.8.1 Common Properties for JUnit and Spring

    You can set repetitive properties by using system properties or Spring configuration properties. Here are their names with their default values:

    Property nameDefault valueDescription

    stubrunner.minPort

    10000

    Minimum value of a port for a started WireMock with stubs.

    stubrunner.maxPort

    15000

    Maximum value of a port for a started WireMock with stubs.

    stubrunner.repositoryRoot

    		 

    Maven repo URL. If blank, then call the local maven repo.

    stubrunner.classifier

    stubs

    Default classifier for the stub artifacts.

    stubrunner.workOffline

    false

    If true, then do not contact any remote repositories to download stubs.

    stubrunner.ids

    		 

    Array of Ivy notation stubs to download.

    stubrunner.username

    		 

    Optional username to access the tool that stores the JARs with stubs.

    stubrunner.password

    		 

    Optional password to access the tool that stores the JARs with stubs.

    stubrunner.stubsPerConsumer

    false

    Set to true if you want to use different stubs for each consumer instead of registering all stubs for every consumer.

    stubrunner.consumerName

    		 

    If you want to use a stub for each consumer and want to -override the consumer name just change this value.

    89.8.2 Stub Runner Stubs IDs

    You can provide the stubs to download via the stubrunner.ids system property. They +override the consumer name just change this value.

    85.8.2 Stub Runner Stubs IDs

    You can provide the stubs to download via the stubrunner.ids system property. They follow this pattern:

    groupId:artifactId:version:classifier:port

    Note that version, classifier and port are optional.

    • If you do not provide the port, a random one will be picked.
    • If you do not provide the classifier, the default is used. (Note that you can pass an empty classifier this way: groupId:artifactId:version:).
    • If you do not provide the version, then the + will be passed and the latest one is downloaded.

    port means the port of the WireMock server.

    [Important]Important

    Starting with version 1.0.4, you can provide a range of versions that you would like the Stub Runner to take into consideration. You can read more about the Aether versioning -ranges here.

    89.9 Stub Runner Docker

    We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image +ranges here.

    85.9 Stub Runner Docker

    We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image that will start the standalone version of Stub Runner.

    If you want to learn more about the basics of Maven, artifact ids, -group ids, classifiers and Artifact Managers, just click here Section 87.6, “Docker Project”.

    89.9.1 How to use it

    Just execute the docker image. You can pass any of the Section 89.8.1, “Common Properties for JUnit and Spring” +group ids, classifiers and Artifact Managers, just click here Section 83.6, “Docker Project”.

    85.9.1 How to use it

    Just execute the docker image. You can pass any of the Section 85.8.1, “Common Properties for JUnit and Spring” as environment variables. The convention is that all the letters should be upper case. The camel case notation should and the dot (.) should be separated via underscore (_). E.g. the stubrunner.repositoryRoot property should be represented - as a STUBRUNNER_REPOSITORY_ROOT environment variable.

    89.9.2 Example of client side usage in a non JVM project

    We’d like to use the stubs created in this Section 87.6.4, “Server side (nodejs)” step. + as a STUBRUNNER_REPOSITORY_ROOT environment variable.

    85.9.2 Example of client side usage in a non JVM project

    We’d like to use the stubs created in this Section 83.6.4, “Server side (nodejs)” step. Let’s assume that we want to run the stubs on port 9876. The NodeJS code is available here:

    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
 $ cd bookstore

    Let’s run the Stub Runner Boot application with the stubs.

    # Provide the Spring Cloud Contract Docker version
@@ -8175,11 +8099,11 @@ that the stubs are setup properly.
    "Content-Type:application/json" -X POST --data '{ "title" : "Title", "genre" : "Genre", "description" : "Description", "author" : "Author", "publisher" : "Publisher", "pages" : 100, "image_url" : "https://d213dhlpdb53mu.cloudfront.net/assets/pivotal-square-logo-41418bd391196c3022f3cd9f3959b3f6d7764c47873d858583384e759c7db435.svg", "buy_url" : "https://pivotal.io" }' http://localhost:9876/api/books
 # Now time for the second request
 $ curl -X GET http://localhost:9876/api/books
-# You will receive contents of the JSON

    90. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following +# You will receive contents of the JSON

    86. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Apache Camel
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to define which one should be used. Let’s assume that you have both AMQP, Spring Cloud Stream and Spring Integration on the classpath. Then you need to set stubrunner.stream.enabled=false and stubrunner.integration.enabled=false. -That way the only remaining framework is Spring AMQP.

    90.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
+That way the only remaining framework is Spring AMQP.

    86.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
 
 import java.util.Collection;
 import java.util.Map;
@@ -8220,10 +8144,10 @@ That way the only remaining framework is Spring AMQP.
    Map<String, Collection<String>> labels(); }

    For convenience, the StubFinder interface extends StubTrigger, so you only need one -or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    90.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    90.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    90.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    90.1.4 Trigger All Messages

    stubFinder.trigger()

    90.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    86.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    86.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    86.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    86.1.4 Trigger All Messages

    stubFinder.trigger()

    86.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Apache Camel. For the provided artifacts, it automatically downloads the -stubs and registers the required routes.

    90.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

    90.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false +stubs and registers the required routes.

    86.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

    86.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the camelService application:

    └── .m2
     └── repository
@@ -8282,10 +8206,10 @@ receivedMessage.in.headers.get(
    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:input', new BookReturned('foo'), [sample: 'header'])
    You can listen to the output of the message sent to jms:output:
    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)
    The received message passes the following assertions:
    receivedMessage != null
 assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
 receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    90.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    86.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Integration. For the provided artifacts, it automatically downloads -the stubs and registers the required routes.

    90.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    90.3.2 Disabling the functionality

    If you need to disable this functionality, set the +the stubs and registers the required routes.

    86.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    86.3.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.integration.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the integrationService application:

    └── .m2
     └── repository
@@ -8361,7 +8285,7 @@ assertJsons(receivedMessage.payload)
 receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'input')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message passes the following assertions:

    receivedMessage != null
 assertJsons(receivedMessage.payload)
-receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    90.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    86.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Stream. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    [Warning]Warning

    If Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel and no such destination exists, the @@ -8374,8 +8298,8 @@ destination is resolved as a channel name.

    </dependency>

    Gradle.  

    testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

    -

    90.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    90.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false +

    86.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    86.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false property.

    Assume that you have the following Maven repository with a deployed stubs for the streamService application:

    └── .m2
     └── repository
@@ -8442,7 +8366,7 @@ receivedMessage.headers.get(destination:
    messaging.send(new BookReturned('foo'), [sample: 'header'], 'bookStorage')
    To listen to the output of the message sent to returnBook:
    Message<?> receivedMessage = messaging.receive('returnBook')
    The received message passes the following assertions:
    receivedMessage != null
 assertJsons(receivedMessage.payload)
 receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the output -destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    90.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to +destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    86.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to integrate with Spring AMQP’s Rabbit Template. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    The integration tries to work standalone (that is, without interaction with a running RabbitMQ message broker). It expects a RabbitTemplate on the application context and @@ -8454,7 +8378,7 @@ queues. Bindings connect an exchange to a queue. If message contracts are trigge Spring AMQP stub runner integration looks for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find message listeners bound to these queues. The message is triggered for all matching -message listeners.

    90.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and +message listeners.

    86.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. Remember to annotate your test class with @AutoConfigureStubRunner.

    [Important]Important

    If you already have Stream and Integration on the classpath, you need to disable them explicitly by setting the stubrunner.stream.enabled=false and @@ -8526,7 +8450,7 @@ definition is matched and invoked with the contract message.

    ConnectionFactory.
    To disable the mocked ConnectionFactory, set the following property:
 stubrunner.amqp.mockConnection=false
    stubrunner:
   amqp:
-    mockConnection: false
    91. Contract DSL
    Spring Cloud Contract supports out of the box 2 types of DSL. One written in
+    mockConnection: false

    87. Contract DSL

    Spring Cloud Contract supports out of the box 2 types of DSL. One written in Groovy and one written in YAML.

    If you decide to write the contract in Groovy, do not be alarmed if you have not used Groovy before. Knowledge of the language is not really needed, as the Contract DSL uses only a tiny subset of it (only literals, method calls and closures). Also, the DSL is statically @@ -8620,13 +8544,13 @@ response: regex: bar - key: foo3 command: andMeToo($it)

    [Tip]Tip

    You can compile contracts to stubs mapping using standalone maven command: -mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert

    91.1 Limitations

    [Warning]Warning

    Spring Cloud Contract Verifier does not properly support XML. Please use JSON or +mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert

    87.1 Limitations

    [Warning]Warning

    Spring Cloud Contract Verifier does not properly support XML. Please use JSON or help us implement this feature.

    [Warning]Warning

    The support for verifying the size of JSON arrays is experimental. If you want to turn it on, please set the value of the following system property to true: spring.cloud.contract.verifier.assert.size. By default, this feature is set to false. You can also provide the assertJsonSize property in the plugin configuration.

    [Warning]Warning

    Because JSON structure can have any form, it can be impossible to parse it properly when using the Groovy DSL and the value(consumer(…​), producer(…​)) notation in GString. That -is why you should use the Groovy Map notation.

    91.2 Common Top-Level elements

    The following sections describe the most common top-level elements:

    91.2.1 Description

    You can add a description to your contract. The description is arbitrary text. The +is why you should use the Groovy Map notation.

    87.2 Common Top-Level elements

    The following sections describe the most common top-level elements:

    87.2.1 Description

    You can add a description to your contract. The description is arbitrary text. The following code shows an example:

    Groovy DSL.  

    		org.springframework.cloud.contract.spec.Contract.make {
 			description('''
@@ -8684,7 +8608,7 @@ response:
         regex: bar
       - key: foo3
         command: andMeToo($it)

    -

    91.2.2 Name

    You can provide a name for your contract. Assume that you provided the following name: +

    87.2.2 Name

    You can provide a name for your contract. Assume that you provided the following name: should register a user. If you do so, the name of the autogenerated test is validate_should_register_a_user. Also, the name of the stub in a WireMock stub is should_register_a_user.json.

    [Important]Important

    You must ensure that the name does not contain any characters that make the @@ -8696,14 +8620,14 @@ override each other.

    Groovy DSL.  }

    YAML.  

    name: some name

    -

    91.2.3 Ignoring Contracts

    If you want to ignore a contract, you can either set a value of ignored contracts in the +

    87.2.3 Ignoring Contracts

    If you want to ignore a contract, you can either set a value of ignored contracts in the plugin configuration or set the ignored property on the contract itself:

    Groovy DSL.  

    org.springframework.cloud.contract.spec.Contract.make {
 	ignored()
 }

    YAML.  

    ignored: true

    -

    91.2.4 Passing Values from Files

    Starting with version 1.2.0, you can pass values from files. Assume that you have the +

    87.2.4 Passing Values from Files

    Starting with version 1.2.0, you can pass values from files. Assume that you have the following resources in our project.

    └── src
     └── test
         └── resources
@@ -8740,7 +8664,7 @@ response:
   bodyFromFile: response.json

    Further assume that the JSON files is as follows:

    request.json

    { "status" : "REQUEST" }

    response.json

    { "status" : "RESPONSE" }

    When test or stub generation takes place, the contents of the file is passed to the body of a request or a response. The name of the file needs to be a file with location -relative to the folder in which the contract lays.

    91.2.5 HTTP Top-Level Elements

    The following methods can be called in the top-level closure of a contract definition. +relative to the folder in which the contract lays.

    87.2.5 HTTP Top-Level Elements

    The following methods can be called in the top-level closure of a contract definition. request and response are mandatory. priority is optional.

    Groovy DSL.  

    org.springframework.cloud.contract.spec.Contract.make {
 	// Definition of HTTP request part of the contract
@@ -8770,7 +8694,7 @@ response:
 ...

    [Important]Important

    If you want to make your contract have a higher value of priority you need to pass a lower number to the priority tag / method. E.g. priority with -value 5 has higher priority than priority with value 10.

    91.3 Request

    The HTTP protocol requires only method and url to be specified in a request. The +value 5 has higher priority than priority with value 10.

    87.3 Request

    The HTTP protocol requires only method and url to be specified in a request. The same information is mandatory in request definition of the Contract.

    Groovy DSL.  

    org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -9035,7 +8959,7 @@ parametrization of either fileName or "transformers" : [ "response-template", "foo-transformer" ]
   }
 }
-	'''

    91.4 Response

    The response must contain an HTTP status code and may contain other information. The + '''

    87.4 Response

    The response must contain an HTTP status code and may contain other information. The following code shows an example:

    Groovy DSL.  

    org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -9052,12 +8976,12 @@ following code shows an example:
    Groovy DSL. 
 ...
 status: 200

    Besides status, the response may contain headers and a body, both of which are -specified the same way as in the request (see the previous paragraph).

    91.5 Dynamic properties

    The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not +specified the same way as in the request (see the previous paragraph).

    87.5 Dynamic properties

    The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not want to force the consumers to stub their clocks to always return the same value of time so that it gets matched by the stub.

    For Groovy DSL you can provide the dynamic parts in your contracts in two ways: pass them directly in the body or set them in separate sections called -testMatchers and stubMatchers.

    For YAML you can only use the matchers section.

    91.5.1 Dynamic properties inside the body

    [Important]Important

    This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can set the properties inside the body either with the value method or, if you use +testMatchers and stubMatchers.

    For YAML you can only use the matchers section.

    87.5.1 Dynamic properties inside the body

    [Important]Important

    This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can set the properties inside the body either with the value method or, if you use the Groovy map notation, with $(). The following example shows how to set dynamic properties with the value method:

    value(consumer(...), producer(...))
 value(c(...), p(...))
@@ -9066,8 +8990,8 @@ value(client(...), server(...))

    The following example shows how to set d $(c(...), p(...)) $(stub(...), test(...)) $(client(...), server(...))

    Both approaches work equally well. stub and client methods are aliases over the consumer -method. Subsequent sections take a closer look at what you can do with those values.

    91.5.2 Regular expressions

    [Important]Important

    This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can use regular expressions to write your requests in Contract DSL. Doing so is +method. Subsequent sections take a closer look at what you can do with those values.

    87.5.2 Regular expressions

    [Important]Important

    This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can use regular expressions to write your requests in Contract DSL. Doing so is particularly useful when you want to indicate that a given response should be provided for requests that follow a given pattern. Also, you can use regular expressions when you need to use patterns and not exact values both for your test and your server side tests.

    The following example shows how to use regular expressions to write a request:

    org.springframework.cloud.contract.spec.Contract.make {
@@ -9213,8 +9137,8 @@ String nonBlank() {
 				message: "User not found by email = [${value(producer(regex(email())), consumer('not.existing@user.com'))}]"
 		)
 	}
-}

    91.5.3 Passing Optional Parameters

    [Important]Important

    This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    It is possible to provide optional parameters in your contract. However, you can provide +}

    87.5.3 Passing Optional Parameters

    [Important]Important

    This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    It is possible to provide optional parameters in your contract. However, you can provide optional parameters only for the following:

    • STUB side of the Request
    • TEST side of the Response

    The following example shows how to provide optional parameters:

    org.springframework.cloud.contract.spec.Contract.make {
 	priority 1
 	request {
@@ -9279,8 +9203,8 @@ expression that must be present 0 or more times.
    If you use Spock for, the
   },
   "priority" : 1
 }
-'''

    91.5.4 Executing Custom Methods on the Server Side

    [Important]Important

    This section is valid only for Groovy DSL. Check out the -Section 91.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can define a method call that executes on the server side during the test. Such a +'''

    87.5.4 Executing Custom Methods on the Server Side

    [Important]Important

    This section is valid only for Groovy DSL. Check out the +Section 87.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature.

    You can define a method call that executes on the server side during the test. Such a method can be added to the class defined as "baseClassForTests" in the configuration. The following code shows an example of the contract portion of the test case:

    org.springframework.cloud.contract.spec.Contract.make {
 	request {
@@ -9343,7 +9267,7 @@ It should resemble the following code:
    "/something");
 
 // then:
- assertThat(response.statusCode()).isEqualTo(200);

    91.5.5 Referencing the Request from the Response

    The best situation is to provide fixed values, but sometimes you need to reference a + assertThat(response.statusCode()).isEqualTo(200);

    87.5.5 Referencing the Request from the Response

    The best situation is to provide fixed values, but sometimes you need to reference a request in your response.

    If you’re writing contracts using Groovy DSL, you can use the fromRequest() method, which lets you reference a bunch of elements from the HTTP request. You can use the following options:

    • fromRequest().url(): Returns the request URL and query parameters.
    • fromRequest().query(String key): Returns the first query parameter with a given name.
    • fromRequest().query(String key, int index): Returns the nth query parameter with a @@ -9491,7 +9415,7 @@ in sending the following response body:

      }
      [Important]Important

      This feature works only with WireMock having a version greater than or equal to 2.5.1. The Spring Cloud Contract Verifier uses WireMock’s response-template response transformer. It uses Handlebars to convert the Mustache {{{ }}} templates into -proper values. Additionally, it registers two helper functions:

      • escapejsonbody: Escapes the request body in a format that can be embedded in a JSON.
      • jsonpath: For a given parameter, find an object in the request body.

    91.5.6 Registering Your Own WireMock Extension

    WireMock lets you register custom extensions. By default, Spring Cloud Contract registers +proper values. Additionally, it registers two helper functions:

    • escapejsonbody: Escapes the request body in a format that can be embedded in a JSON.
    • jsonpath: For a given parameter, find an object in the request body.

    87.5.6 Registering Your Own WireMock Extension

    WireMock lets you register custom extensions. By default, Spring Cloud Contract registers the transformer, which lets you reference a request from a response. If you want to provide your own extensions, you can register an implementation of the org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions interface. @@ -9523,7 +9447,7 @@ org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExte } }

    [Important]Important

    Remember to override the applyGlobally() method and set it to false if you -want the transformation to be applied only for a mapping that explicitly requires it.

    91.5.7 Dynamic Properties in the Matchers Sections

    If you work with Pact, the following discussion may seem familiar. +want the transformation to be applied only for a mapping that explicitly requires it.

    87.5.7 Dynamic Properties in the Matchers Sections

    If you work with Pact, the following discussion may seem familiar. Quite a few users are used to having a separation between the body and setting the dynamic parts of a contract.

    You can use two separate sections:

    • stubMatchers, which lets you define the dynamic values that should end up in a stub. You can set it in the request or inputMessage part of your contract.
    • testMatchers, which is present in the response or outputMessage side of the @@ -9928,7 +9852,7 @@ and: assertThat(parsedJson.read("\$.events[0].eventId", String.class)).matches("^([a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})\$") assertThat(parsedJson.read("\$.events[0].status", String.class)).matches(".+")

      As you can see, the assertion is malformed. Only the first element of the array got asserted. In order to fix this, you should apply the assertion to the whole $.events -collection and assert it with the byCommand(…​) method.

    91.6 JAX-RS Support

    The Spring Cloud Contract Verifier supports the JAX-RS 2 Client API. The base class needs +collection and assert it with the byCommand(…​) method.

    87.6 JAX-RS Support

    The Spring Cloud Contract Verifier supports the JAX-RS 2 Client API. The base class needs to define protected WebTarget webTarget and server initialization. The only option for testing JAX-RS API is to start a web server. Also, a request with a body needs to have a content type set. Otherwise, the default of application/octet-stream gets used.

    In order to use JAX-RS mode, use the following settings:

    testMode == 'JAXRSCLIENT'

    The following example shows a generated test API:

    '''
@@ -9953,7 +9877,7 @@ content type set. Otherwise, the default of application/oc
  // and:
   DocumentContext parsedJson = JsonPath.parse(responseAsString);
   assertThatJson(parsedJson).field("['property1']").isEqualTo("a");
-'''

    91.7 Async Support

    If you’re using asynchronous communication on the server side (your controllers are +'''

    87.7 Async Support

    If you’re using asynchronous communication on the server side (your controllers are returning Callable, DeferredResult, and so on), then, inside your contract, you must provide a sync() method in the response section. The following code shows an example:

    Groovy DSL.  

    org.springframework.cloud.contract.spec.Contract.make {
@@ -9970,7 +9894,7 @@ provide a sync() method in the response:
     async: true

    -

    91.8 Working with Context Paths

    Spring Cloud Contract supports context paths.

    [Important]Important

    The only change needed to fully support context paths is the switch on the +

    87.8 Working with Context Paths

    Spring Cloud Contract supports context paths.

    [Important]Important

    The only change needed to fully support context paths is the switch on the PRODUCER side. Also, the autogenerated tests must use EXPLICIT mode. The consumer side remains untouched. In order for the generated test to pass, you must use EXPLICIT mode.

    Maven.  @@ -10014,8 +9938,8 @@ socket.

    Consider the following contract:

    or
 	}
 }

    If you do it this way:

    • All of your requests in the autogenerated tests are sent to the real endpoint with your context path included (for example, /my-context-path/url).
    • Your contracts reflect that you have a context path. Your generated stubs also have -that information (for example, in the stubs, you have to call /my-context-path/url).

    91.9 Messaging Top-Level Elements

    The DSL for messaging looks a little bit different than the one that focuses on HTTP. The -following sections explain the differences:

    91.9.1 Output Triggered by a Method

    The output message can be triggered by calling a method (such as a Scheduler when a was +that information (for example, in the stubs, you have to call /my-context-path/url).

    87.9 Messaging Top-Level Elements

    The DSL for messaging looks a little bit different than the one that focuses on HTTP. The +following sections explain the differences:

    87.9.1 Output Triggered by a Method

    The output message can be triggered by calling a method (such as a Scheduler when a was started and a message was sent), as shown in the following example:

    Groovy DSL.  

    def dsl = Contract.make {
 	// Human readable description
@@ -10060,7 +9984,7 @@ outputMessage:
 
    In the previous example case, the output message is sent to output if a method called
 bookReturnedTriggered is executed. On the message publisher’s side, we generate a
 test that calls that method to trigger the message. On the consumer side, you can use
-the some_label to trigger the message.

    91.9.2 Output Triggered by a Message

    The output message can be triggered by receiving a message, as shown in the following +the some_label to trigger the message.

    87.9.2 Output Triggered by a Message

    The output message can be triggered by receiving a message, as shown in the following example:

    Groovy DSL.  

    def dsl = Contract.make {
 	description 'Some Description'
@@ -10116,7 +10040,7 @@ outputMessage:
 received on the input destination. On the message publisher’s side, the engine
 generates a test that sends the input message to the defined destination. On the
 consumer side, you can either send a message to the input destination or use a label
-(some_label in the example) to trigger the message.

    91.9.3 Consumer/Producer

    [Important]Important

    This section is valid only for Groovy DSL.

    In HTTP, you have a notion of client/stub and `server/test notation. You can also +(some_label in the example) to trigger the message.

    87.9.3 Consumer/Producer

    [Important]Important

    This section is valid only for Groovy DSL.

    In HTTP, you have a notion of client/stub and `server/test notation. You can also use those paradigms in messaging. In addition, Spring Cloud Contract Verifier also provides the consumer and producer methods, as presented in the following example (note that you can use either $ or value methods to provide consumer and producer @@ -10137,10 +10061,10 @@ parts):

    Contract.make {
 				bookName: 'foo'
 		])
 	}
-}

    91.9.4 Common

    In the input or outputMessage section you can call assertThat with the name +}

    87.9.4 Common

    In the input or outputMessage section you can call assertThat with the name of a method (e.g. assertThatMessageIsOnTheQueue()) that you have defined in the base class or in a static import. Spring Cloud Contract will execute that method -in the generated test.

    91.10 Multiple Contracts in One File

    You can define multiple contracts in one file. Such a contract might resemble the +in the generated test.

    87.10 Multiple Contracts in One File

    You can define multiple contracts in one file. Such a contract might resemble the following example:

    Groovy DSL.  

    import org.springframework.cloud.contract.spec.Contract
 
@@ -10229,10 +10153,10 @@ index of the contract in the list.
    The generated stubs is shown in the fol
 1_WithList.json

    As you can see, the first file got the name parameter from the contract. The second got the name of the contract file (WithList.groovy) prefixed with the index (in this case, the contract had an index of 1 in the list of contracts in the file).

    [Tip]Tip

    As you can see, it iss much better if you name your contracts because doing so makes -your tests far more meaningful.

    92. Customization

    [Important]Important

    This section is valid only for Groovy DSL

    You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in -the remainder of this section.

    92.1 Extending the DSL

    You can provide your own functions to the DSL. The key requirement for this feature is to +your tests far more meaningful.

    88. Customization

    [Important]Important

    This section is valid only for Groovy DSL

    You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in +the remainder of this section.

    88.1 Extending the DSL

    You can provide your own functions to the DSL. The key requirement for this feature is to maintain the static compatibility. Later in this document, you can see examples of:

    • Creating a JAR with reusable classes.
    • Referencing of these classes in the DSLs.

    You can find the full example -here.

    92.1.1 Common JAR

    The following examples show three classes that can be reused in the DSLs.

    PatternUtils contains functions used by both the consumer and the producer.

    package com.example;
+here.
    88.1.1 Common JAR
    The following examples show three classes that can be reused in the DSLs.
    PatternUtils contains functions used by both the consumer and the producer.
    package com.example;
 
 import java.util.regex.Pattern;
 
@@ -10363,8 +10287,8 @@ maintain the static compatibility. Later in this document, you can see examples
 		return new ServerDslProperty( PatternUtils.ok(), "OK");
 	}
 }
-//end::impl[]
    92.1.2 Adding the Dependency to the Project
    In order for the plugins and IDE to be able to reference the common JAR classes, you need
-to pass the dependency to your project.
    92.1.3 Test the Dependency in the Project’s Dependencies
    First, add the common jar dependency as a test dependency. Because your contracts files
+//end::impl[]

    88.1.2 Adding the Dependency to the Project

    In order for the plugins and IDE to be able to reference the common JAR classes, you need +to pass the dependency to your project.

    88.1.3 Test the Dependency in the Project’s Dependencies

    First, add the common jar dependency as a test dependency. Because your contracts files are available on the test resources path, the common jar classes automatically become visible in your Groovy files. The following examples show how to test the dependency:

    Maven.  

    <dependency>
@@ -10375,7 +10299,7 @@ visible in your Groovy files. The following examples show how to test the depend
 </dependency>

    Gradle.  

    testCompile("com.example:beer-common:0.0.1-SNAPSHOT")

    -

    92.1.4 Test a Dependency in the Plugin’s Dependencies

    Now, you must add the dependency for the plugin to reuse at runtime, as shown in the +

    88.1.4 Test a Dependency in the Plugin’s Dependencies

    Now, you must add the dependency for the plugin to reuse at runtime, as shown in the following example:

    Maven.  

    <plugin>
 	<groupId>org.springframework.cloud</groupId>
@@ -10402,7 +10326,7 @@ following example:
    Maven. 
 </plugin>

    Gradle.  

    classpath "com.example:beer-common:0.0.1-SNAPSHOT"

    -

    92.1.5 Referencing classes in DSLs

    You can now reference your classes in your DSL, as shown in the following example:

    package contracts.beer.rest
+

    88.1.5 Referencing classes in DSLs

    You can now reference your classes in your DSL, as shown in the following example:

    package contracts.beer.rest
 
 import com.example.ConsumerUtils
 import com.example.ProducerUtils
@@ -10443,12 +10367,12 @@ then:
 			contentType(applicationJson())
 		}
 	}
-}

    93. Using the Pluggable Architecture

    You may encounter cases where you have your contracts have been defined in other formats, +}

    89. Using the Pluggable Architecture

    You may encounter cases where you have your contracts have been defined in other formats, such as YAML, RAML or PACT. In those cases, you still want to benefit from the automatic generation of tests and stubs. You can add your own implementation for generating both tests and stubs. Also, you can customize the way tests are generated (for example, you can generate tests for other languages) and the way stubs are generated (for example, you -can generate stubs for other HTTP server implementations).

    93.1 Custom Contract Converter

    The ContractConverter interface lets you register your own implementation of a contract +can generate stubs for other HTTP server implementations).

    89.1 Custom Contract Converter

    The ContractConverter interface lets you register your own implementation of a contract structure converter. The following code listing shows the ContractConverter interface:

    package org.springframework.cloud.contract.spec
 
 /**
@@ -10490,9 +10414,9 @@ structure converter. The following code listing shows the 
 conversion. Also, you must define how to perform that conversion in both directions.
    [Important]Important
    Once you create your implementation, you must create a
 /META-INF/spring.factories file in which you provide the fully qualified name of your
 implementation.
    The following example shows a typical spring.factories file:
    org.springframework.cloud.contract.spec.ContractConverter=\
-org.springframework.cloud.contract.verifier.converter.YamlContractConverter
    93.1.1 Pact Converter
    Spring Cloud Contract includes support for Pact representation of
+org.springframework.cloud.contract.verifier.converter.YamlContractConverter

    89.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of contracts. Instead of using the Groovy DSL, you can use Pact files. In this section, we -present how to add Pact support for your project.

    93.1.2 Pact Contract

    Consider following example of a Pact contract, which is a file under the +present how to add Pact support for your project.

    89.1.2 Pact Contract

    Consider following example of a Pact contract, which is a file under the src/test/resources/contracts folder.

    {
   "provider": {
     "name": "Provider"
@@ -10546,7 +10470,7 @@ present how to add Pact support for your project.
    "version": "2.4.18" } } -}

    The remainder of this section about using Pact refers to the preceding file.

    93.1.3 Pact for Producers

    On the producer side, you mustadd two additional dependencies to your plugin +}

    The remainder of this section about using Pact refers to the preceding file.

    89.1.3 Pact for Producers

    On the producer side, you mustadd two additional dependencies to your plugin configuration. One is the Spring Cloud Contract Pact support, and the other represents the current Pact version that you use.

    Maven.  

    <plugin>
@@ -10616,7 +10540,7 @@ test might be as follows:
    "Content-Type" : "application/vnd.fraud.v1+json;charset=UTF-8"
     }
   }
-}

    93.1.4 Pact for Consumers

    On the producer side, you must add two additional dependencies to your project +}

    89.1.4 Pact for Consumers

    On the producer side, you must add two additional dependencies to your project dependencies. One is the Spring Cloud Contract Pact support, and the other represents the current Pact version that you use.

    Maven.  

    <dependency>
@@ -10633,7 +10557,7 @@ current Pact version that you use.
    Maven. 
 
    Gradle. 
 
    testCompile "org.springframework.cloud:spring-cloud-contract-spec-pact"
 testCompile 'au.com.dius:pact-jvm-model:2.4.18'
    
-

    93.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the +

    89.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the way the verifier builds Java tests, you can register your own implementation.

    The SingleTestGenerator interface lets you register your own implementation. The following code listing shows the SingleTestGenerator interface:

    package org.springframework.cloud.contract.verifier.builder
 
@@ -10668,7 +10592,7 @@ following code listing shows the SingleTestGenerator
    Again, you must provide a spring.factories file, such as the one shown in the following
 example:
    org.springframework.cloud.contract.verifier.builder.SingleTestGenerator=/
-com.example.MyGenerator

    93.3 Using the Custom Stub Generator

    If you want to generate stubs for stub servers other than WireMock, you can plug in your +com.example.MyGenerator

    89.3 Using the Custom Stub Generator

    If you want to generate stubs for stub servers other than WireMock, you can plug in your own implementation of the StubGenerator interface. The following code listing shows the StubGenerator interface:

    package org.springframework.cloud.contract.verifier.converter
 
@@ -10710,7 +10634,7 @@ own implementation of the StubGenerator interface.
 example:
    # Stub converters
 org.springframework.cloud.contract.verifier.converter.StubGenerator=\
 org.springframework.cloud.contract.verifier.wiremock.DslToWireMockClientConverter
    The default implementation is the WireMock stub generation.
    [Tip]Tip
    You can provide multiple stub generator implementations. For example, from a single
-DSL, you can produce both WireMock stubs and Pact files.

    93.4 Using the Custom Stub Runner

    If you decide to use a custom stub generation, you also need a custom way of running +DSL, you can produce both WireMock stubs and Pact files.

    89.4 Using the Custom Stub Runner

    If you decide to use a custom stub generation, you also need a custom way of running stubs with your different stub provider.

    Assume that you use Moco to build your stubs and that you have written a stub generator and placed your stubs in a JAR file.

    In order for Stub Runner to know how to run your stubs, you have to define a custom HTTP Stub server implementation, which might resemble the following example:

    package org.springframework.cloud.contract.stubrunner.provider.moco
@@ -10793,7 +10717,7 @@ HTTP Stub server implementation, which might resemble the following example:
    
 }

    Then, you can register it in your spring.factories file, as shown in the following example:

    org.springframework.cloud.contract.stubrunner.HttpServerStub=\
 org.springframework.cloud.contract.stubrunner.provider.moco.MocoHttpServerStub

    Now you can run stubs with Moco.

    [Important]Important

    If you do not provide any implementation, then the default (WireMock) -implementation is used. If you provide more than one, the first one on the list is used.

    93.5 Using the Custom Stub Downloader

    You can customize the way your stubs are downloaded by creating an implementation of the +implementation is used. If you provide more than one, the first one on the list is used.

    89.5 Using the Custom Stub Downloader

    You can customize the way your stubs are downloaded by creating an implementation of the StubDownloaderBuilder interface, as shown in the following example:

    package com.example;
 
 class CustomStubDownloaderBuilder implements StubDownloaderBuilder {
@@ -10820,7 +10744,7 @@ com.example.CustomStubDownloaderBuilder

    Now you can pick a folder with t If you use the repositoryRoot property or the workOffline flag, then an Aether-based implementation that downloads stubs from a remote repository is used. If you do not provide these values, the ClasspathStubProvider (which will scan the classpath) is -used. If you provide more than one, then the first one on the list is used.

    94. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a +used. If you provide more than one, then the first one on the list is used.

    90. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is @@ -10850,7 +10774,7 @@ your test. The following code shows an example:

    <
 server port can be bound in the test application context with the "wiremock.server.port"
 property. Using @AutoConfigureWireMock adds a bean of type WiremockConfiguration to
 your test application context, where it will be cached in between methods and classes
-having the same context, the same as for Spring integration tests.
    94.1 Registering Stubs Automatically
    If you use @AutoConfigureWireMock, it registers WireMock JSON stubs from the file
+having the same context, the same as for Spring integration tests.
    90.1 Registering Stubs Automatically
    If you use @AutoConfigureWireMock, it registers WireMock JSON stubs from the file
 system or classpath (by default, from file:src/test/resources/mappings). You can
 customize the locations using the stubs attribute in the annotation, which can be an
 Ant-style resource pattern or a directory. In the case of a directory, */.json is
@@ -10869,7 +10793,7 @@ public class WiremockImportApplicationTests {
 
 }
    [Note]Note

    Actually, WireMock always loads mappings from src/test/resources/mappings as well as the custom locations in the stubs attribute. To change this behavior, you can -also specify a files root as described in the next section of this document.

    94.2 Using Files to Specify the Stub Bodies

    WireMock can read response bodies from files on the classpath or the file system. In that +also specify a files root as described in the next section of this document.

    90.2 Using Files to Specify the Stub Bodies

    WireMock can read response bodies from files on the classpath or the file system. In that case, you can see in the JSON DSL that the response has a bodyFileName instead of a (literal) body. The files are resolved relative to a root directory (by default, src/test/resources/__files). To customize this location you can set the files @@ -10880,7 +10804,7 @@ supported. A list of values can be given, in which case WireMock resolves the fi that exists when it needs to find a response body.

    [Note]Note

    When you configure the files root, it also affects the automatic loading of stubs, because they come from the root location in a subdirectory called "mappings". The value of files has no -effect on the stubs loaded explicitly from the stubs attribute.

    94.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop +effect on the stubs loaded explicitly from the stubs attribute.

    90.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop the server. To do so, use the WireMockSpring convenience class to obtain an Options instance, as shown in the following example:

    @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@@ -10906,7 +10830,7 @@ instance, as shown in the following example:
    
 	}
 
 }
    The @ClassRule means that the server shuts down after all the methods in this class
-have been run.

    94.4 Relaxed SSL Validation for Rest Template

    WireMock lets you stub a "secure" server with an "https" URL protocol. If your +have been run.

    90.4 Relaxed SSL Validation for Rest Template

    WireMock lets you stub a "secure" server with an "https" URL protocol. If your application wants to contact that stub server in an integration test, it will find that the SSL certificates are not valid (the usual problem with self-installed certificates). The best option is often to re-configure the client to use "http". If that’s not an @@ -10932,7 +10856,7 @@ annotation or the stub runner. If you use the JUnit @Rule< classpath and it is selected by the RestTemplateBuilder and configured to ignore SSL errors. If you use the default java.net client, you do not need the annotation (but it won’t do any harm). There is no support currently for other clients, but it may be added -in future releases.

    94.5 WireMock and Spring MVC Mocks

    Spring Cloud Contract provides a convenience class that can load JSON WireMock stubs into +in future releases.

    90.5 WireMock and Spring MVC Mocks

    Spring Cloud Contract provides a convenience class that can load JSON WireMock stubs into a Spring MockRestServiceServer. The following code shows an example:

    @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment = WebEnvironment.NONE)
 public class WiremockForDocsMockServerApplicationTests {
@@ -10963,7 +10887,7 @@ pattern. The JSON format is the normal WireMock format, which you can read about
 WireMock website.
    Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as
 Spring Boot embedded servers, and Wiremock itself has "native" support for a particular
 version of Jetty (currently 9.2). To use the native Jetty, you need to add the native
-Wiremock dependencies and exclude the Spring Boot container (if there is one).

    94.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type +Wiremock dependencies and exclude the Spring Boot container (if there is one).

    90.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type in order to customize the WireMock configuration (e.g. add custom transformers). Example:

    		@Bean WireMockConfigurationCustomizer optionsCustomizer() {
 			return new WireMockConfigurationCustomizer() {
@@ -10971,7 +10895,7 @@ Example:
    		// perform your customization here
 				}
 			};
-		}

    94.7 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate + }

    90.7 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate documentation (for example in Asciidoctor format) for an HTTP API with Spring MockMvc or Rest Assured. At the same time that you generate documentation for your API, you can also generate WireMock stubs by using Spring Cloud Contract WireMock. To do so, write your @@ -11057,7 +10981,7 @@ available on the classpath (by stubs as JARs, for example). After that, you can create a stub using WireMock in a number of different ways, including by using @AutoConfigureWireMock(stubs="classpath:resource.json"), as described earlier in this -document.

    94.8 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST +document.

    90.8 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST Docs. If you do so in combination with Spring Cloud WireMock, you get both the contracts and the stubs.

    Why would you want to use this feature? Some people in the community asked questions about a situation in which they would like to move to DSL-based contract definition, @@ -11107,8 +11031,8 @@ Contract.make { } } }

    The generated document (formatted in Asciidoc in this case) contains a formatted -contract. The location of this file would be index/dsl-contract.adoc.

    95. Migrations

    This section covers migrating from one version of Spring Cloud Contract Verifier to the -next version. It covers the following versions upgrade paths:

    95.1 1.0.x → 1.1.x

    This section covers upgrading from version 1.0 to version 1.1.

    95.1.1 New structure of generated stubs

    In 1.1.x we have introduced a change to the structure of generated stubs. If you have +contract. The location of this file would be index/dsl-contract.adoc.

    91. Migrations

    This section covers migrating from one version of Spring Cloud Contract Verifier to the +next version. It covers the following versions upgrade paths:

    91.1 1.0.x → 1.1.x

    This section covers upgrading from version 1.0 to version 1.1.

    91.1.1 New structure of generated stubs

    In 1.1.x we have introduced a change to the structure of generated stubs. If you have been using the @AutoConfigureWireMock notation to use the stubs from the classpath, it no longer works. The following example shows how the @AutoConfigureWireMock notation used to work:

    @AutoConfigureWireMock(stubs = "classpath:/customer-stubs/mappings", port = 8084)

    You must either change the location of the stubs to: @@ -11186,20 +11110,20 @@ structure presented in the previous snippet.

    Maven.&nbs from "${project.buildDir}/resources/main/customer-stubs/META-INF/${project.group}/${project.name}/${project.version}" into "${project.buildDir}/resources/main/customer-stubs" }

    -

    95.2 1.1.x → 1.2.x

    This section covers upgrading from version 1.1 to version 1.2.

    95.2.1 Custom HttpServerStub

    HttpServerStub includes a method that was not in version 1.1. The method is +

    91.2 1.1.x → 1.2.x

    This section covers upgrading from version 1.1 to version 1.2.

    91.2.1 Custom HttpServerStub

    HttpServerStub includes a method that was not in version 1.1. The method is String registeredMappings() If you have classes that implement HttpServerStub, you now have to implement the registeredMappings() method. It should return a String representing all mappings available in a single HttpServerStub.

    See issue 355 for more -detail.

    95.2.2 New packages for generated tests

    The flow for setting the generated tests package name will look like this:

    • Set basePackageForTests
    • If basePackageForTests was not set, pick the package from baseClassForTests
    • If baseClassForTests was not set, pick packageWithBaseClasses
    • If nothing got set, pick the default value: +detail.

    91.2.2 New packages for generated tests

    The flow for setting the generated tests package name will look like this:

    • Set basePackageForTests
    • If basePackageForTests was not set, pick the package from baseClassForTests
    • If baseClassForTests was not set, pick packageWithBaseClasses
    • If nothing got set, pick the default value: org.springframework.cloud.contract.verifier.tests

    See issue 260 for more -detail.

    95.2.3 New Methods in TemplateProcessor

    In order to add support for fromRequest.path, the following methods had to be added to the +detail.

    91.2.3 New Methods in TemplateProcessor

    In order to add support for fromRequest.path, the following methods had to be added to the TemplateProcessor interface:

    • path()
    • path(int index)

    See issue 388 for more -detail.

    95.2.4 RestAssured 3.0

    Rest Assured, used in the generated test classes, got bumped to 3.0. If +detail.

    91.2.4 RestAssured 3.0

    Rest Assured, used in the generated test classes, got bumped to 3.0. If you manually set versions of Spring Cloud Contract and the release train you might see the following exception:

    Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project some-project: Compilation failure: Compilation failure:
 [ERROR] /some/path/SomeClass.java:[4,39] package com.jayway.restassured.response does not exist

    This exception will occur due to the fact that the tests got generated with an old version of plugin and at test execution time you have an incompatible -version of the release train (and vice versa).

    Done via issue 267

    96. Links

    The following links may be helpful when working with Spring Cloud Contract Verifier:

    92. Links

    The following links may be helpful when working with Spring Cloud Contract Verifier:

    Part XIV. Spring Cloud Vault

    © 2016-2017 The original authors.

    [Note]Note

    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.

    97. Quick Start

    Prerequisites

    To get started with Vault and this guide you need a +Marcin Grzejszczak

    Part XIII. Spring Cloud Vault

    © 2016-2017 The original authors.

    [Note]Note

    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.

    93. Quick Start

    Prerequisites

    To get started with Vault and this guide you need a *NIX-like operating systems that provides:

    • wget, openssl and unzip
    • at least Java 7 and a properly configured JAVA_HOME environment variable

    Install Vault

    $ src/test/bash/install_vault.sh

    Create SSL certificates for Vault

    $ src/test/bash/create_certificates.sh
    [Note]Note

    create_certificates.sh creates certificates in work/ca and a JKS truststore work/keystore.jks. If you want to run Spring Cloud Vault using this quickstart guide you need to configure the truststore the spring.cloud.vault.ssl.trust-store property to file:work/keystore.jks.

    Start Vault server

    $ src/test/bash/local_run_vault.sh

    Vault is started listening on 0.0.0.0:8200 using the inmem storage and https. Vault is sealed and not initialized when starting up.

    [Note]Note

    If you want to run tests, leave Vault uninitialized. The tests will @@ -11241,9 +11165,9 @@ backend is enabled which accesses secret config settings via JSON endpoints.

    SpringApplication (i.e. what is normally "application" in a regular Spring Boot app), "profile" is an active profile (or comma-separated list of properties). Properties retrieved from Vault will be used "as-is" -without further prefixing of the property names.

    98. Client Side Usage

    To use these features in an application, just build it as a Spring +without further prefixing of the property names.

    94. Client Side Usage

    To use these features in an application, just build it as a Spring Boot application that depends on spring-cloud-vault-config (e.g. see -the test cases). Example Maven configuration:

    Example 98.1. pom.xml

    <parent>
+the test cases). Example Maven configuration:
    Example 94.1. pom.xml
    <parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
     <version>1.5.4.RELEASE</version>
@@ -11254,7 +11178,7 @@ the test cases). Example Maven configuration:
    <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-vault-config</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
@@ -11288,7 +11212,7 @@ the test cases). Example Maven configuration:
    8200 if it is running. To modify
 the startup behavior you can change the location of the Vault server
 using bootstrap.properties (like application.properties but for
-the bootstrap phase of an application context), e.g.
    Example 98.2. bootstrap.yml
    spring.cloud.vault:
+the bootstrap phase of an application context), e.g.
    Example 94.2. bootstrap.yml
    spring.cloud.vault:
     host: localhost
     port: 8200
     scheme: https
@@ -11304,24 +11228,24 @@ additional configuration like
 SSL and
 authentication.
    If the application imports the spring-boot-starter-actuator project, the
 status of the vault server will be available via the /health endpoint.
    The vault health indicator can be enabled or disabled through the
-property health.vault.enabled (default true).
    98.1 Authentication
    Vault requires an authentication mechanism to authorize client requests.
    Spring Cloud Vault supports multiple authentication mechanisms to authenticate applications with Vault.
    For a quickstart, use the root token printed by the Vault initialization.
    Example 98.3. bootstrap.yml
    spring.cloud.vault:
-    token: 19aefa97-cccc-bbbb-aaaa-225940e63d76

    [Warning]Warning
    Consider carefully your security requirements. Static token authentication is fine if you want quickly get started with Vault, but a static token is not protected any further. Any disclosure to unintended parties allows Vault use with the associated token roles.
    99. Authentication methods
    Different organizations have different requirements for security
+property health.vault.enabled (default true).
    94.1 Authentication
    Vault requires an authentication mechanism to authorize client requests.
    Spring Cloud Vault supports multiple authentication mechanisms to authenticate applications with Vault.
    For a quickstart, use the root token printed by the Vault initialization.
    Example 94.3. bootstrap.yml
    spring.cloud.vault:
+    token: 19aefa97-cccc-bbbb-aaaa-225940e63d76

    [Warning]Warning
    Consider carefully your security requirements. Static token authentication is fine if you want quickly get started with Vault, but a static token is not protected any further. Any disclosure to unintended parties allows Vault use with the associated token roles.
    95. Authentication methods
    Different organizations have different requirements for security
 and authentication. Vault reflects that need by shipping multiple authentication
-methods. Spring Cloud Vault supports token and AppId authentication.
    99.1 Token authentication
    Tokens are the core method for authentication within Vault.
+methods. Spring Cloud Vault supports token and AppId authentication.
    95.1 Token authentication
    Tokens are the core method for authentication within Vault.
 Token authentication requires a static token to be provided using the
 Bootstrap Application Context.
    [Note]Note
    Token authentication is the default authentication method.
 If a token is disclosed an unintended party gains access to Vault and
-can access secrets for the intended client.
    Example 99.1. bootstrap.yml
    spring.cloud.vault:
+can access secrets for the intended client.

    Example 95.1. bootstrap.yml

    spring.cloud.vault:
     authentication: TOKEN
     token: 00000000-0000-0000-0000-000000000000

    • authentication setting this value to TOKEN selects the Token -authentication method
    • token sets the static token to use

    See also: Vault Documentation: Tokens

    99.2 AppId authentication

    Vault supports AppId +authentication method

  • token sets the static token to use

    • See also: Vault Documentation: Tokens

    95.2 AppId authentication

    Vault supports AppId authentication that consists of two hard to guess tokens. The AppId defaults to spring.application.name that is statically configured. The second token is the UserId which is a part determined by the application, usually related to the runtime environment. IP address, Mac address or a Docker container name are good examples. Spring Cloud Vault Config supports IP address, Mac address and static UserId’s (e.g. supplied via System properties). -The IP and Mac address are represented as Hex-encoded SHA256 hash.

    IP address-based UserId’s use the local host’s IP address.

    Example 99.2. bootstrap.yml using SHA256 IP-Address UserId’s

    spring.cloud.vault:
+The IP and Mac address are represented as Hex-encoded SHA256 hash.
    IP address-based UserId’s use the local host’s IP address.
    Example 95.2. bootstrap.yml using SHA256 IP-Address UserId’s
    spring.cloud.vault:
     authentication: APPID
     app-id:
         user-id: IP_ADDRESS

    • authentication setting this value to APPID selects the AppId
@@ -11331,42 +11255,42 @@ so make sure to include the -n flag.
      <
 localhost-bound device. The configuration also allows specifying
 a network-interface hint to pick the right device. The value of
 network-interface is optional and can be either an interface
-name or interface index (0-based).
      Example 99.3. bootstrap.yml using SHA256 Mac-Address UserId’s
      spring.cloud.vault:
+name or interface index (0-based).
      Example 95.3. bootstrap.yml using SHA256 Mac-Address UserId’s
      spring.cloud.vault:
     authentication: APPID
     app-id:
         user-id: MAC_ADDRESS
         network-interface: eth0

      • network-interface sets network interface to obtain the physical address
      The corresponding command to generate the IP address UserId from a command line is:
      $ echo -n 0AFEDE1234AC | sha256sum
      [Note]Note
      The Mac address is specified uppercase and without colons.
 Including the line break of echo leads to a different hash value
-so make sure to include the -n flag.
      99.2.1 Custom UserId
      The UserId generation is an open mechanism. You can set
+so make sure to include the -n flag.
      95.2.1 Custom UserId
      The UserId generation is an open mechanism. You can set
 spring.cloud.vault.app-id.user-id to any string and the configured
 value will be used as static UserId.
      A more advanced approach lets you set spring.cloud.vault.app-id.user-id to a
 classname. This class must be on your classpath and must implement
 the org.springframework.cloud.vault.AppIdUserIdMechanism interface
 and the createUserId method. Spring Cloud Vault will obtain the UserId
 by calling createUserId each time it authenticates using AppId to
-obtain a token.
      Example 99.4. bootstrap.yml
      spring.cloud.vault:
+obtain a token.
      Example 95.4. bootstrap.yml
      spring.cloud.vault:
     authentication: APPID
     app-id:
-        user-id: com.examlple.MyUserIdMechanism

      Example 99.5. MyUserIdMechanism.java
      public class MyUserIdMechanism implements AppIdUserIdMechanism {
+        user-id: com.examlple.MyUserIdMechanism

      Example 95.5. MyUserIdMechanism.java
      public class MyUserIdMechanism implements AppIdUserIdMechanism {
 
   @Override
   public String createUserId() {
     String userId = ...
     return userId;
   }
-}

      See also: Vault Documentation: Using the App ID auth backend
      99.3 AppRole authentication
      AppRole is intended for machine
-authentication, like the deprecated (since Vault 0.6.1) Section 99.2, “AppId authentication”.
+}

      See also: Vault Documentation: Using the App ID auth backend

    95.3 AppRole authentication

    AppRole is intended for machine +authentication, like the deprecated (since Vault 0.6.1) Section 95.2, “AppId authentication”. AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.

    Spring Vault supports AppRole authentication by providing either RoleId only or together with a provided SecretId (push or pull mode).

    RoleId and optionally SecretId must be provided by configuration, -Spring Vault will not look up these or create a custom SecretId.

    Example 99.6. bootstrap.yml with AppRole authentication properties

    spring.cloud.vault:
+Spring Vault will not look up these or create a custom SecretId.
    Example 95.6. bootstrap.yml with AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
-        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    • role-id sets the RoleId.
    Example 99.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
+        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    • role-id sets the RoleId.
    Example 95.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
         role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
         secret-id: 1696536f-1976-73b1-b241-0b4213908d39
-        app-auth-path: approle

    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
    • approle-path sets the path of the approle authentication mount to use
    See also: Vault Documentation: Using the AppRole auth backend

    99.4 AWS-EC2 authentication

    The aws-ec2 + app-auth-path: approle


    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
    • approle-path sets the path of the approle authentication mount to use

    See also: Vault Documentation: Using the AppRole auth backend

    95.4 AWS-EC2 authentication

    The aws-ec2 auth backend provides a secure introduction mechanism for AWS EC2 instances, allowing automated retrieval of a Vault token. Unlike most Vault authentication backends, this backend @@ -11374,7 +11298,7 @@ does not require first-deploying, or provisioning security-sensitive credentials (tokens, username/password, client certificates, etc.). Instead, it treats AWS as a Trusted Third Party and uses the cryptographically signed dynamic metadata information that uniquely -represents each EC2 instance.

    Example 99.8. bootstrap.yml using AWS-EC2 Authentication

    spring.cloud.vault:
+represents each EC2 instance.
    Example 95.8. bootstrap.yml using AWS-EC2 Authentication
    spring.cloud.vault:
     authentication: AWS_EC2

    AWS-EC2 authentication enables nonce by default to follow
 the Trust On First Use (TOFU) principle. Any unintended party that
 gains access to the PKCS#7 identity metadata can authenticate
@@ -11385,17 +11309,17 @@ party does not have the nonce and can raise an alert in Vault for
 further investigation.
    The nonce is kept in memory and is lost during application restart.
 You can configure a static nonce with spring.cloud.vault.aws-ec2.nonce.
    AWS-EC2 authentication roles are optional and default to the AMI.
 You can configure the authentication role by setting the
-spring.cloud.vault.aws-ec2.role property.
    Example 99.9. bootstrap.yml with configured role
    spring.cloud.vault:
+spring.cloud.vault.aws-ec2.role property.
    Example 95.9. bootstrap.yml with configured role
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
-        role: application-server

    Example 99.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
+        role: application-server

    Example 95.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
         role: application-server
         aws-ec2-path: aws-ec2
         identity-document: http://...
         nonce: my-static-nonce

    • authentication setting this value to AWS_EC2 selects the AWS EC2
-authentication method
    • role sets the name of the role against which the login is being attempted.
    • aws-ec2-path sets the path of the AWS EC2 mount to use
    • identity-document sets URL of the PKCS#7 AWS EC2 identity document
    • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    See also: Vault Documentation: Using the aws auth backend
    99.5 AWS-IAM authentication
    The aws backend provides a secure
+authentication method
  • role sets the name of the role against which the login is being attempted.
  • aws-ec2-path sets the path of the AWS EC2 mount to use
  • identity-document sets URL of the PKCS#7 AWS EC2 identity document
  • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    • See also: Vault Documentation: Using the aws auth backend
    95.5 AWS-IAM authentication
    The aws backend provides a secure
 authentication mechanism for AWS IAM roles, allowing the automatic authentication with
 vault based on the current IAM role of the running application.
  Unlike most Vault authentication backends, this backend
@@ -11409,39 +11333,39 @@ will use the IAM role assigned to the ECS task of the running container.
 If you are running your application naked on top of an EC2 instance then
 the IAM role used will be the one assigned to the EC2 instance.
    When using the AWS-IAM authentication you must create a role in Vault
 and assign it to your IAM role. An empty role defaults to
-the friendly name the current IAM role.
    Example 99.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
-    authentication: AWS_IAM

    Example 99.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
+the friendly name the current IAM role.
    Example 95.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
+    authentication: AWS_IAM

    Example 95.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
     authentication: AWS_IAM
     aws-iam:
         role: my-dev-role
         aws-path: aws
         server-id: some.server.name

    • role sets the name of the role against which the login is being attempted. This should be bound to your IAM role. If one is not supplied then the friendly name of the current IAM user will be used as the vault role.
    • aws-path sets the path of the AWS mount to use
    • server-id sets the value to use for the X-Vault-AWS-IAM-Server-ID header preventing certain types of replay attacks.
    AWS-IAM requires the AWS Java SDK dependency (com.amazonaws:aws-java-sdk-core)
-as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    99.6 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
-certificates that are either signed by a CA or self-signed.
    To enable cert authentication you need to:
    1. Use SSL, see Chapter 105, Vault Client SSL configuration
    2. Configure a Java Keystore that contains the client
-certificate and the private key
    3. Set the spring.cloud.vault.authentication to CERT
    Example 99.13. bootstrap.yml
    spring.cloud.vault:
+as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    95.6 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
+certificates that are either signed by a CA or self-signed.
    To enable cert authentication you need to:
    1. Use SSL, see Chapter 101, Vault Client SSL configuration
    2. Configure a Java Keystore that contains the client
+certificate and the private key
    3. Set the spring.cloud.vault.authentication to CERT
    Example 95.13. bootstrap.yml
    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend
    99.7 Cubbyhole authentication
    Cubbyhole authentication uses Vault primitives to provide a secured authentication
+        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend

    95.7 Cubbyhole authentication

    Cubbyhole authentication uses Vault primitives to provide a secured authentication workflow. Cubbyhole authentication uses tokens as primary login method. An ephemeral token is used to obtain a second, login VaultToken from Vault’s Cubbyhole secret backend. The login token is usually longer-lived and used to interact with Vault. The login token will be retrieved from a wrapped -response stored at /cubbyhole/response.

    Creating a wrapped token

    [Note]Note

    Response Wrapping for token creation requires Vault 0.6.0 or higher.

    Example 99.14. Creating and storing tokens

    $ vault token-create -wrap-ttl="10m"
+response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 95.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
 Key                            Value
 ---                            -----
 wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
 wrapping_token_ttl:            0h10m0s
 wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
-wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 99.15. bootstrap.yml
    spring.cloud.vault:
+wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 95.15. bootstrap.yml
    spring.cloud.vault:
     authentication: CUBBYHOLE
-    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:

    99.8 Kubernetes authentication

    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token. -The authentication is role based and the role is bound to a service account name and a namespace.

    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

    Example 99.16. bootstrap.yml with all Kubernetes authentication properties

    spring.cloud.vault:
+    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:

    95.8 Kubernetes authentication

    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token. +The authentication is role based and the role is bound to a service account name and a namespace.

    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

    Example 95.16. bootstrap.yml with all Kubernetes authentication properties

    spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
-        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

    • role sets the Role.
    • service-account-token-file sets the location of the file containing the Kubernetes Service Account Token. Defaults to /var/run/secrets/kubernetes.io/serviceaccount/token.

    See also:

    100. Secret Backends

    100.1 Generic Backend

    Spring Cloud Vault supports at the basic level the generic secret + service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token


    • role sets the Role.
    • service-account-token-file sets the location of the file containing the Kubernetes Service Account Token. Defaults to /var/run/secrets/kubernetes.io/serviceaccount/token.

    See also:

    96. Secret Backends

    96.1 Generic Backend

    Spring Cloud Vault supports at the basic level the generic secret backend. The generic secret backend allows storage of arbitrary values as key-value store. A single context can store one or many key-value tuples. Contexts can be organized hierarchically. @@ -11461,13 +11385,13 @@ No active profiles will skip accessing contexts with a profile name.

    Prope default-context: application application-name: my-app

    • enabled setting this value to false disables the secret backend config usage
    • backend sets the path of the secret mount to use
    • default-context sets the context name used by all applications
    • application-name overrides the application name for use in the generic backend
    • profile-separator separates the profile name from the context in -property sources with profiles

    See also: Vault Documentation: Using the generic secret backend

    100.2 Consul

    Spring Cloud Vault can obtain credentials for HashiCorp Consul. +property sources with profiles

    See also: Vault Documentation: Using the generic secret backend

    96.2 Consul

    Spring Cloud Vault can obtain credentials for HashiCorp Consul. The Consul integration requires the spring-cloud-vault-config-consul -dependency.

    Example 100.1. pom.xml

    <dependencies>
+dependency.
    Example 96.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -11479,12 +11403,12 @@ the property name by setting spring.cloud.vault.consul.tok
         enabled: true
         role: readonly
         backend: consul
-        token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored

    See also: Vault Documentation: Setting up Consul with Vault

    100.3 RabbitMQ

    Spring Cloud Vault can obtain credentials for RabbitMQ.

    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq -dependency.

    Example 100.2. pom.xml

    <dependencies>
+        token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored

    See also: Vault Documentation: Setting up Consul with Vault

    96.3 RabbitMQ

    Spring Cloud Vault can obtain credentials for RabbitMQ.

    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq +dependency.

    Example 96.2. pom.xml

    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting spring.cloud.vault.rabbitmq.enabled=true (default false) @@ -11498,12 +11422,12 @@ by setting spring.cloud.vault.rabbitmq.username-property role: readonly backend: rabbitmq username-property: spring.rabbitmq.username - password-property: spring.rabbitmq.password

    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored

    See also: Vault Documentation: Setting up RabbitMQ with Vault

    100.4 AWS

    Spring Cloud Vault can obtain credentials for AWS.

    The AWS integration requires the spring-cloud-vault-config-aws -dependency.

    Example 100.3. pom.xml

    <dependencies>
+        password-property: spring.rabbitmq.password
    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored

    See also: Vault Documentation: Setting up RabbitMQ with Vault

    96.4 AWS

    Spring Cloud Vault can obtain credentials for AWS.

    The AWS integration requires the spring-cloud-vault-config-aws +dependency.

    Example 96.3. pom.xml

    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting spring.cloud.vault.aws=true (default false) @@ -11517,24 +11441,24 @@ by setting spring.cloud.vault.aws.access-key-property role: readonly backend: aws access-key-property: cloud.aws.credentials.accessKey - secret-key-property: cloud.aws.credentials.secretKey

    • enabled setting this value to true enables the AWS backend config usage
    • role sets the role name of the AWS role definition
    • backend sets the path of the AWS mount to use
    • access-key-property sets the property name in which the AWS access key is stored
    • secret-key-property sets the property name in which the AWS secret key is stored

    See also: Vault Documentation: Setting up AWS with Vault

    101. Database backends

    Vault supports several database secret backends to generate database + secret-key-property: cloud.aws.credentials.secretKey

    • enabled setting this value to true enables the AWS backend config usage
    • role sets the role name of the AWS role definition
    • backend sets the path of the AWS mount to use
    • access-key-property sets the property name in which the AWS access key is stored
    • secret-key-property sets the property name in which the AWS secret key is stored

    See also: Vault Documentation: Setting up AWS with Vault

    97. Database backends

    Vault supports several database secret backends to generate database credentials dynamically based on configured roles. This means services that need to access a database no longer need to configure credentials: they can request them from Vault, and use Vault’s leasing -mechanism to more easily roll keys.

    Spring Cloud Vault integrates with these backends:

    Using a database secret backend requires to enable the +mechanism to more easily roll keys.

    Spring Cloud Vault integrates with these backends:

    Using a database secret backend requires to enable the backend in the configuration and the spring-cloud-vault-config-databases dependency.

    Vault ships since 0.7.1 with a dedicated database secret backend that allows database integration via plugins. You can use that specific backend by adapting one of the JDBC database properties above. Make sure to specify the appropriate -backend path, e.g. spring.cloud.vault.mysql.role.backend=database.

    Example 101.1. pom.xml

    <dependencies>
+backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 97.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-databases</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>1.3.8.RELEASE</version>
     </dependency>
 </dependencies>

    [Note]Note
    Enabling multiple JDBC-compliant databases will generate credentials
 and store them by default in the same property keys hence property names for
-JDBC secrets need to be configured separately.
    101.1 Apache Cassandra
    Spring Cloud Vault can obtain credentials for Apache Cassandra.
+JDBC secrets need to be configured separately.
    97.1 Apache Cassandra
    Spring Cloud Vault can obtain credentials for Apache Cassandra.
 The integration can be enabled by setting
 spring.cloud.vault.cassandra.enabled=true (default false) and
 providing the role name with spring.cloud.vault.cassandra.role=….
    Username and password are stored in spring.data.cassandra.username
@@ -11548,7 +11472,7 @@ You can configure the property names by setting
         role: readonly
         backend: cassandra
         username-property: spring.data.cassandra.username
-        password-property: spring.data.cassandra.username
    • enabled setting this value to true enables the Cassandra backend config usage
    • role sets the role name of the Cassandra role definition
    • backend sets the path of the Cassandra mount to use
    • username-property sets the property name in which the Cassandra username is stored
    • password-property sets the property name in which the Cassandra password is stored

    See also: Vault Documentation: Setting up Apache Cassandra with Vault

    101.2 MongoDB

    Spring Cloud Vault can obtain credentials for MongoDB. + password-property: spring.data.cassandra.username

    • enabled setting this value to true enables the Cassandra backend config usage
    • role sets the role name of the Cassandra role definition
    • backend sets the path of the Cassandra mount to use
    • username-property sets the property name in which the Cassandra username is stored
    • password-property sets the property name in which the Cassandra password is stored

    See also: Vault Documentation: Setting up Apache Cassandra with Vault

    97.2 MongoDB

    Spring Cloud Vault can obtain credentials for MongoDB. The integration can be enabled by setting spring.cloud.vault.mongodb.enabled=true (default false) and providing the role name with spring.cloud.vault.mongodb.role=….

    Username and password are stored in spring.data.mongodb.username @@ -11562,7 +11486,7 @@ You can configure the property names by setting role: readonly backend: mongodb username-property: spring.data.mongodb.username - password-property: spring.data.mongodb.password

    • enabled setting this value to true enables the MongodB backend config usage
    • role sets the role name of the MongoDB role definition
    • backend sets the path of the MongoDB mount to use
    • username-property sets the property name in which the MongoDB username is stored
    • password-property sets the property name in which the MongoDB password is stored

    See also: Vault Documentation: Setting up MongoDB with Vault

    101.3 MySQL

    Spring Cloud Vault can obtain credentials for MySQL. + password-property: spring.data.mongodb.password

    • enabled setting this value to true enables the MongodB backend config usage
    • role sets the role name of the MongoDB role definition
    • backend sets the path of the MongoDB mount to use
    • username-property sets the property name in which the MongoDB username is stored
    • password-property sets the property name in which the MongoDB password is stored

    See also: Vault Documentation: Setting up MongoDB with Vault

    97.3 MySQL

    Spring Cloud Vault can obtain credentials for MySQL. The integration can be enabled by setting spring.cloud.vault.mysql.enabled=true (default false) and providing the role name with spring.cloud.vault.mysql.role=….

    Username and password are stored in spring.datasource.username @@ -11576,7 +11500,7 @@ You can configure the property names by setting role: readonly backend: mysql username-property: spring.datasource.username - password-property: spring.datasource.username

    • enabled setting this value to true enables the MySQL backend config usage
    • role sets the role name of the MySQL role definition
    • backend sets the path of the MySQL mount to use
    • username-property sets the property name in which the MySQL username is stored
    • password-property sets the property name in which the MySQL password is stored

    See also: Vault Documentation: Setting up MySQL with Vault

    101.4 PostgreSQL

    Spring Cloud Vault can obtain credentials for PostgreSQL. + password-property: spring.datasource.username

    • enabled setting this value to true enables the MySQL backend config usage
    • role sets the role name of the MySQL role definition
    • backend sets the path of the MySQL mount to use
    • username-property sets the property name in which the MySQL username is stored
    • password-property sets the property name in which the MySQL password is stored

    See also: Vault Documentation: Setting up MySQL with Vault

    97.4 PostgreSQL

    Spring Cloud Vault can obtain credentials for PostgreSQL. The integration can be enabled by setting spring.cloud.vault.postgresql.enabled=true (default false) and providing the role name with spring.cloud.vault.postgresql.role=….

    Username and password are stored in spring.datasource.username @@ -11590,7 +11514,7 @@ You can configure the property names by setting role: readonly backend: postgresql username-property: spring.datasource.username - password-property: spring.datasource.username

    • enabled setting this value to true enables the PostgreSQL backend config usage
    • role sets the role name of the PostgreSQL role definition
    • backend sets the path of the PostgreSQL mount to use
    • username-property sets the property name in which the PostgreSQL username is stored
    • password-property sets the property name in which the PostgreSQL password is stored

    See also: Vault Documentation: Setting up PostgreSQL with Vault

    102. Configure PropertySourceLocator behavior

    Spring Cloud Vault uses property-based configuration to create PropertySources + password-property: spring.datasource.username

    • enabled setting this value to true enables the PostgreSQL backend config usage
    • role sets the role name of the PostgreSQL role definition
    • backend sets the path of the PostgreSQL mount to use
    • username-property sets the property name in which the PostgreSQL username is stored
    • password-property sets the property name in which the PostgreSQL password is stored

    See also: Vault Documentation: Setting up PostgreSQL with Vault

    98. Configure PropertySourceLocator behavior

    Spring Cloud Vault uses property-based configuration to create PropertySources for generic and discovered secret backends.

    Discovered backends provide VaultSecretBackendDescriptor beans to describe the configuration state to use secret backend as PropertySource. A SecretBackendMetadataFactory is required to create a SecretBackendMetadata object which contains path, name and property transformation @@ -11609,7 +11533,7 @@ at least one VaultConfigurer bean. You can however } }

    [Note]Note

    All customization is required to happen in the bootstrap context. Add your configuration classes to META-INF/spring.factories at org.springframework.cloud.bootstrap.BootstrapConfiguration -in your application.

    103. Service Registry Configuration

    You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate +in your application.

    99. Service Registry Configuration

    You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate a Vault server by setting spring.cloud.vault.discovery.enabled=true (default false). The net result of that is that your apps need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration. @@ -11623,12 +11547,12 @@ need to provide a scheme metadata entry to be set e If no scheme is configured and the service is not exposed as secure service, then configuration defaults to spring.cloud.vault.scheme which is https when it’s not set.

    spring.cloud.vault.discovery:
     enabled: true
-    service-id: my-vault-service

    104. Vault Client Fail Fast

    In some cases, it may be desirable to fail startup of a service if + service-id: my-vault-service

    100. Vault Client Fail Fast

    In some cases, it may be desirable to fail startup of a service if it cannot connect to the Vault Server. If this is the desired behavior, set the bootstrap configuration property spring.cloud.vault.fail-fast=true and the client will halt with an Exception.

    spring.cloud.vault:
-    fail-fast: true

    105. Vault Client SSL configuration

    SSL can be configured declaratively by setting various properties. + fail-fast: true

    101. Vault Client SSL configuration

    SSL can be configured declaratively by setting various properties. You can set either javax.net.ssl.trustStore to configure JVM-wide SSL settings or spring.cloud.vault.ssl.trust-store to set SSL settings only for Spring Cloud Vault Config.

    spring.cloud.vault:
@@ -11638,7 +11562,7 @@ to set SSL settings only for Spring Cloud Vault Config.
    trust-store-password sets the trust-store password
    Please note that configuring spring.cloud.vault.ssl.* can be only
 applied when either Apache Http Components or the OkHttp client
-is on your class-path.

    106. Lease lifecycle management (renewal and revocation)

    With every secret, Vault creates a lease: +is on your class-path.

    102. Lease lifecycle management (renewal and revocation)

    With every secret, Vault creates a lease: metadata containing information such as a time duration, renewability, and more.

    Vault promises that the data will be valid for the given duration, or Time To Live (TTL). Once the lease is expired, Vault can @@ -11657,7 +11581,7 @@ to false. This is not recommended as leases can exp Spring Cloud Vault cannot longer access Vault or services using generated credentials and valid credentials remain active after application shutdown.

    spring.cloud.vault:
-    config.lifecycle.enabled: true

    See also: Vault Documentation: Lease, Renew, and Revoke

    Part XV. Appendix: Compendium of Configuration Properties

    NameDefaultDescription

    encrypt.fail-on-error

    true

    Flag to say that a process should fail if there is an encryption or decryption + config.lifecycle.enabled: true

    See also: Vault Documentation: Lease, Renew, and Revoke

    Part XIV. Appendix: Compendium of Configuration Properties

    - -Service -Name -Address -Description - - - - -eureka -Eureka Server -http://localhost:8761 -Eureka server for service registration and discovery. All the other services show up in its catalog by default. - - -configserver -Config Server -http://localhost:8888 -Spring Cloud Config Server running in the "native" profile and serving configuration from the local directory ./launcher - - -h2 -H2 Database -http://localhost:9095 (console), jdbc:h2:tcp://localhost:9096/{data} -Relation database service. Use a file path for {data} (e.g. ./target/test) when you connect. Remember that you can add ;MODE=MYSQL or ;MODE=POSTGRESQL to connect with compatibility to other server types. - - -kafka -Kafka Broker -http://localhost:9091 (actuator endpoints), localhost:9092 - - - -hystrixdashboard -Hystrix Dashboard -http://localhost:7979 -Any Spring Cloud app that declares Hystrix circuit breakers publishes metrics on /hystrix.stream. Type that address into the dashboard to visualize all the metrics, - - -dataflow -Dataflow Server -http://localhost:9393 -Spring Cloud Dataflow server with UI at /admin-ui. Connect the Dataflow shell to target at root path. - - -zipkin -Zipkin Server -http://localhost:9411 -Zipkin Server with UI for visualizing traces. Stores span data in memory and accepts them via HTTP POST of JSON data. - - -stubrunner -Stub Runner Boot -http://localhost:8750 -Downloads WireMock stubs, starts WireMock and feeds the started servers with stored stubs. Pass stubrunner.ids to pass stub coordinates and then go to http://localhost:8750/stubs. - - - - -Each of these apps can be configured using a local YAML file with the same name (in the current -working directory or a subdirectory called "config" or in ~/.spring-cloud). E.g. in configserver.yml you might want to -do something like this to locate a local git repository for the backend: - -configserver.yml - -spring: - profiles: - active: git - cloud: - config: - server: - git: - uri: file://${user.home}/dev/demo/config-repo - - -E.g. in Stub Runner app you could fetch stubs from your local .m2 in the following way. - -stubrunner.yml - -stubrunner: - workOffline: true - ids: - - com.example:beer-api-producer:+:9876 - - -
    -Adding Additional Applications -Additional applications can be added to ./config/cloud.yml (not -./config.yml because that would replace the defaults), e.g. with - -config/cloud.yml - -spring: - cloud: - launcher: - deployables: - source: - coordinates: maven://com.example:source:0.0.1-SNAPSHOT - port: 7000 - sink: - coordinates: maven://com.example:sink:0.0.1-SNAPSHOT - port: 7001 - - -when you list the apps: -$ spring cloud --list -source sink configserver dataflow eureka h2 hystrixdashboard kafka stubrunner zipkin -(notice the additional apps at the start of the list). -
    - - -Writing Groovy Scripts and Running Applications -Spring Cloud CLI has support for most of the Spring Cloud declarative -features, such as the @Enable* class of annotations. For example, -here is a fully functional Eureka server - -app.groovy - -@EnableEurekaServer -class Eureka {} - - -which you can run from the command line like this -$ spring run app.groovy -To include additional dependencies, often it suffices just to add the -appropriate feature-enabling annotation, e.g. @EnableConfigServer, -@EnableOAuth2Sso or @EnableEurekaClient. To manually include a -dependency you can use a @Grab with the special "Spring Boot" short -style artifact co-ordinates, i.e. with just the artifact ID (no need -for group or version information), e.g. to set up a client app to -listen on AMQP for management events from the Spring CLoud Bus: - -app.groovy - -@Grab('spring-cloud-starter-bus-amqp') -@RestController -class Service { - @RequestMapping('/') - def home() { [message: 'Hello'] } -} - - - - -Encryption and Decryption -The Spring Cloud CLI comes with an "encrypt" and a "decrypt" -command. Both accept arguments in the same form with a key specified -as a mandatory "--key", e.g. -$ spring encrypt mysecret --key foo -682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda -$ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda -mysecret -To use a key in a file (e.g. an RSA public key for encyption) prepend -the key value with "@" and provide the file path, e.g. -$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub -AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+... - - Spring Cloud Security @@ -12063,7 +11852,7 @@ parameterized using spring.oauth2.sso.serviceId. _Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant -2.0.0.BUILD-SNAPSHOT +1.3.8.RELEASE Spring Cloud Contract @@ -20793,7 +20582,7 @@ the test cases). Example Maven configuration: <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-vault-config</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>1.3.8.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> @@ -21365,7 +21154,7 @@ dependency. <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-vault-config-consul</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>1.3.8.RELEASE</version> </dependency> </dependencies> @@ -21411,7 +21200,7 @@ dependency. <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-vault-config-rabbitmq</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>1.3.8.RELEASE</version> </dependency> </dependencies> @@ -21462,7 +21251,7 @@ dependency. <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-vault-config-aws</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>1.3.8.RELEASE</version> </dependency> </dependencies> @@ -21538,7 +21327,7 @@ backend path, e.g. spring.cloud.vault.mysql.role.backend=database
    NameDefaultDescription

    encrypt.fail-on-error

    true

    Flag to say that a process should fail if there is an encryption or decryption error.

    encrypt.key

    		 

    A symmetric key. As a stronger alternative consider using a keystore.

    encrypt.key-store.alias

    		 

    Alias for a key in the store.

    encrypt.key-store.location

    		 

    Location of the key store file, e.g. classpath:/keystore.jks.

    encrypt.key-store.password

    		 

    Password that locks the keystore.

    encrypt.key-store.secret

    		 

    Secret protecting the key (defaults to the same as the password).

    encrypt.rsa.algorithm

    		 

    The RSA algorithm to use (DEFAULT or OEAP). Once it is set do not change it (or existing ciphers will not a decryptable).

    encrypt.rsa.salt

    deadbeef

    Salt for the random secret used to encrypt cipher text. Once it is set do not change it (or existing ciphers will not a decryptable).

    encrypt.rsa.strong

    false

    Flag to indicate that "strong" AES encryption should be used internally. If diff --git a/Edgware.SR3/spring-cloud.xml b/Edgware.SR3/spring-cloud.xml index e846bfcd..8ffbdd8a 100644 --- a/Edgware.SR3/spring-cloud.xml +++ b/Edgware.SR3/spring-cloud.xml @@ -17,7 +17,7 @@ Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry. -Version: 2.0.0.BUILD-SNAPSHOT +Version: 1.3.8.RELEASE Features @@ -604,7 +604,7 @@ in downstream projects. You can also disable the creation of these beans by set Spring Cloud Config -2.0.0.BUILD-SNAPSHOT +1.3.8.RELEASE Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration. @@ -2117,7 +2117,7 @@ String name = "World"; Spring Cloud Netflix -2.0.0.BUILD-SNAPSHOT +1.3.8.RELEASE This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your @@ -9028,7 +9028,7 @@ packages to scan. Spring Cloud Sleuth Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer -2.0.0.BUILD-SNAPSHOT +1.3.8.RELEASE Introduction @@ -10777,7 +10777,7 @@ class ReporterConfiguration { Spring Cloud Consul -2.0.0.BUILD-SNAPSHOT +1.3.8.RELEASE This project provides Consul integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your @@ -11492,221 +11492,10 @@ my.project.CustomCuratorFrameworkConfig,\ my.project.DefaultCuratorFrameworkConfig +Unresolved directive in spring-cloud.adoc - include::../../../../cli/docs/src/main/asciidoc/spring-cloud-cli.adoc[] - -Spring Boot Cloud CLI - -Spring Boot CLI provides Spring -Boot command line features for Spring -Cloud. You can write Groovy scripts to run Spring Cloud component -applications (e.g. @EnableEurekaServer). You can also easily do -things like encryption and decryption to support Spring Cloud Config -clients with secret configuration values. With the Launcher CLI you -can launch services like Eureka, Zipkin, Config Server -conveniently all at once from the command line (very useful at -development time). - -Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github. - - - -Installation -To install, make -sure you have -Spring Boot CLI -(1.5.2 or better): -$ spring version -Spring CLI v1.5.4.RELEASE -E.g. for SDKMan users -$ sdk install springboot 1.5.4.RELEASE -$ sdk use springboot 1.5.4.RELEASE -and install the Spring Cloud plugin -$ mvn install -$ spring install org.springframework.cloud:spring-cloud-cli:1.4.0.BUILD-SNAPSHOT - -Prerequisites: to use the encryption and decryption features -you need the full-strength JCE installed in your JVM (it’s not there by default). -You can download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" -from Oracle, and follow instructions for installation (essentially replace the 2 policy files -in the JRE lib/security directory with the ones that you downloaded). - - - -Running Spring Cloud Services in Development -The Launcher CLI can be used to run common services like Eureka, -Config Server etc. from the command line. To list the available -services you can do spring cloud --list, and to launch a default set -of services just spring cloud. To choose the services to deploy, -just list them on the command line, e.g. -$ spring cloud eureka configserver h2 kafka stubrunner zipkin -Summary of supported deployables: - - - - - - -