spring cloud

This Week in Spring: Interviews, Releases, and Spring Tutorials

Hi, Spring fans! Welcome to another installment of This Week in Spring. I’m in Tokyo, Japan, for the epic SpringOne Tour Japan event, and then, it’s off to Seoul, South Korea, and then Singapore. I’m trying to keep busy! I delivered two 3+ hour long talks yesterday, despite a blistering fever, and today, I presented at the SpringOne Tour. Tonight, I had the honor of presenting at a joint meeting of the JJUG and JSUG here in Tokyo on Tuesday evening (starting about 7 hours ago).

If you’re out and about in Tokyo, don’t hesitate to say hi! I’d love to chat with ya about anything and everything Pivotal and Spring! Anyway, we’ve got a ton to get to, so let’s get started!

Original Link

This Week in Spring: Spring Boot, Releases, and Cloud

Hi, Spring fans! Welcome to another installment of This Week in Spring! This week, I’m in Paris, France, for the amazing Voxxed Microservices event. This has been quite the show, and I’m grateful for having had the opportunity to attend. Now, as I write this, I’m preparing to go to Beijing, China, for the first leg in Asia of the SpringOne Tour show. I’ll be in China, then Japan, Korea, Singapore, Hong Kong, Taiwan, Los Angeles, Morocco, Seattle, Toronto, and then finally, in mid-December, I’ll return home to San Francisco. We’ve got a ton of things to look at this week, so without further ado, let’s get to it!

Original Link

This Week in Spring: Spring Security OAuth, Releases, Cloud, and More

Hi, Spring fans! Welcome to another installment of This Week in Spring! This week, I’m in Toronto, Canada, where I’ve been speaking to customers and at a meetup, then it’s off to St. Petersburg, Russia, for the epic Joker conf 2018. As usual, we’ve got a ton to cover, so let’s get to it!

Original Link

This Week in Spring: SpringOne Tour, Releases, and SpringOne Platform Wrap-Up

Hi, Spring fans! This week, I’m in sunny San Francisco for the epic SpringOne Tour San Francisco event. I’m head down and preparing for a large amount of travel ahead of me. Starting on the 14th, I’ll start four weeks of travel, bringing the message far-and-wide to Toronto, St. Petersburg, Brussels, San Francisco, Hartford, Paris, Beijing, Tokyo, Singapore, Seoul, Hong Kong, and… I forget… but, there’s more! I’m so looking forward to seeing you all at each and every one of those places!

I also loved this tweet from Pivotal:

Original Link

Spring Boot Listener for AWS SQS With Spring Cloud

Spring Cloud AWS makes it easy to create a Java method that listens for messages on an Amazon SQS queue.  Between Spring Boot and Spring Cloud, I was surprised by just how little code I needed to make all this happen.

The key is that when you have the right dependencies in your Maven POM, all you have to do is annotate your listener method with  @SqsListener:

Original Link

Bootiful GCP: To Production!

Hi, Spring fans! In this series, we have looked at the Spring Cloud integration for the Google Cloud Platform, called Spring Cloud GCP. Spring Cloud GCP represents a joint effort between Google and Pivotal that endeavors to provide a first-class experience for Spring Cloud developers when using the Google Cloud Platform. Pivotal Cloud Foundry users will enjoy an even easier integration with the GCP service broker. I wrote these installments with input from Google Cloud Developer Advocate, and my buddy, Ray Tsang. You can also catch a walkthrough of Spring Cloud GCP in our Google Next 2018 session, Bootiful Google Cloud Platform. Thanks, buddy! As always, I’d love to hear from you if you have feedback.

As we’ve worked through these examples, we’ve relied on the default authentication of the Google Cloud SDKs and Spring Cloud GCP, working with a local installation of the Google Cloud SDK and the gcloud CLI. Spring Cloud GCP’s auto-configuration configures a DefaultCredentialsProvider that looks for some way to authenticate. Everything’s worked fine on our local machine so far, because we ran the interactive authentication prompt and confirmed on the Google Cloud website the linking of our authorities to this application. But, what if you want to run tests in a CI environment or deploy the application to a cloud platform?

Original Link

Service Discovery and Client-Side Load Balancing With Eureka and Ribbon

Today, we are going to build an application with load balancing and service discovery. Traditionally, a load balancer is a separate application running that has all server nodes, as well. We will build an application where the client does not need to remember the IPs of a server, and we can dynamically add and remove nodes.

Let’s start with app1 and app 2, which are two applications or servers with REST endpoints, such as /process . We are going to discover and load balance it. App1 and app2 will register themselves into the Eureka server with the name app-producer whenever they get started.

Original Link

Bootiful GCP: Use Spring Cloud GCP to Connect to Other GCP Services

Hi, Spring fans! In this brief part of the series, we’re going to look at the Spring Cloud integration for Google Cloud Platform, Spring Cloud GCP. Spring Cloud GCP represents a joint effort between Google and Pivotal that endeavors to provide a first-class experience for Spring Cloud developers when using the Google Cloud Platform. Pivotal Cloud Foundry users will enjoy an even easier integration with the GCP service broker. I wrote these installments with input from Google Cloud Developer Advocate, and my buddy, Ray Tsang. You can also catch a walkthrough of Spring Cloud GCP in our Google Next 2018 session, Bootiful Google Cloud Platform. Thanks, buddy! As always, I’d love to hear from you if you have feedback. Let’s get into it.

The Spring Cloud GCP project strives to provide integrations with Spring and some of the GCP services that map well to Spring. But, GCP is vast! There is a good deal of other services out there that you can consume via their direct Java SDK or even through their REST APIs directly. Spring Cloud GCP can make working with those APIs a bit easier, too! In this section, we’re going to integrate the Google Cloud Vision API, which supports analyzing images and doing feature detection.

Original Link

Bootiful GCP: Supporting Observability With Spring Cloud GCP Stackdriver Trace

Hi, Spring fans! In this brief series, we’re going to look at the Spring Cloud integration for Google Cloud Platform, called Spring Cloud GCP. Spring Cloud GCP represents a joint effort between Google and Pivotal that endeavors to provide a first-class experience for Spring Cloud developers when using the Google Cloud Platform. Pivotal Cloud Foundry users will enjoy an even easier integration with the GCP service broker. These installments were written with help from Google Cloud Developer Advocate, and my buddy, Ray Tsang. You can also catch a walkthrough of Spring Cloud GCP in our Google Next 2018 session, Bootiful Google Cloud Platform. Thanks, buddy!

As we move more and more applications to the cloud and introduce more and more microservices, the complexity of understanding what’s gone wrong and where grows. Distributed tracing addresses this problem. Distributed tracing, in theory, is a simple chore. For every request that enters or exits the system and for every ingress or egress int the system, we need to attach a UUID, if one isn’t already present. If it is present, then propagate it. Unfortunately, this sort of logic is tedious and hard to get right as requests move from one node to another, synchronously and asynchronously across thread and network boundaries. Spring Cloud Sleuth addresses this problem and provides an SPI that back-end distributed tracing systems, like OpenZipkin and Google Cloud Stack Driver, can plugin.

Original Link

Bootiful GCP: Getting Started With Spring Cloud for Google Cloud Platform

Hi, Spring fans! In this brief 8 part series, we’re going to look at the Spring Cloud integration for Google Cloud Platform, called Spring Cloud GCP. Spring Cloud GCP represents a joint effort between Google and Pivotal that endeavors to provide a first class experience for Spring Cloud developers when using the Google Cloud Platform. Pivotal Cloud Foundry users will enjoy an even easier integration with the GCP service broker. I wrote these installments with input from Google Cloud Developer Advocate, and my buddy, Ray Tsang. You can also catch a walkthrough of Spring Cloud GCP in our Google Next 2018 session, Bootiful Google Cloud Platform. Thanks buddy! As always, I’d love to hear from you if you have feedback.

In this installment, we’re going to introduce Spring Cloud GCP and then set up a trivial project using Spring Cloud GCP.

Original Link

This Week in Spring: SpringOne Platform, KNative, and More

Hi, Spring fans, and welcome to another installment of This Week in Spring. This week, I’ve been in smokey Seattle, and I just arrived in the hot-n-humid NYC to visit customers and Spring teammates. We’ve got so much to cover, so without further ado, let’s get to it!

The Spring team are all heads down as we near the epic SpringOne Platform 2018 event. Are you going to be there? It’s going to be September 24-27th, 2018, in Washington, DC. Do not miss this premier event uniting practitioners of agile, Cloud Foundry, Kubernetes, DevOps, and — of course — Spring in one place.

Original Link

This Week in Spring: Spring Security, KNative, Spring Cloud, and More!

Hi Spring fans! Welcome to another installment of This Week in Spring! This week I’m in San Francisco in studio with Spring Security lead Rob Winch, filming our new Spring Security Livelessons video. There is so much to cover that, as you can imagine, it’s a tall order even for the two of us!

I’m also busily preparing for my talk with my buddy and Googler Ray Tsang at this week’s Google Cloud NEXT event on all things Pivotal and Google Cloud. We’re going to look at the bootiful Spring Cloud GCP project and, importantly, the new project jointly announced between Google and Pivotal just this morning — KNative. KNative will serve as the platform that we at Pivotal have built and deployed on our Project Riff serverless function-as-a-service runtime. Do not miss it if you’re around!

Alright, we’ve got a lot to cover related to Pivotal, Google, KNative, Spring, and so much more, so let’s get to it!

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.


java ,spring ,spring boot ,reactive spring ,pivotal ,spring cloud ,spring rest docs ,spring security ,knative ,google

Original Link

Continuous Integration With Jenkins, Artifactory, and Spring Cloud Contract

Contract Driven Contract (CDC) testing is a method that allows you to verify integration between applications within your system. The number of such interactions may be really large especially if you maintain microservices-based architecture. Assuming that every microservice is developed by different teams or sometimes even different vendors, it is important to automate the whole testing process. As usual, we can use the Jenkins server for running contract tests within our Continuous Integration (CI) process.

The sample scenario has been visualized on the picture below. We have one application (person-service) that exposes API leveraged by three different applications. Each application is implementing by a different development team. Consequently, every application is stored in a separated Git repository and has a dedicated pipeline in Jenkins for building, testing, and deploying.

The source code of sample applications is available on GitHub in the repository sample-spring-cloud-contract-ci. I placed all the sample microservices in the single Git repository only for our demo simplification. We will still treat them as a separated microservices, developed and built independently.

In this article, I used Spring Cloud Contract for CDC implementation. It is the first choice solution for JVM applications written in Spring Boot. Contracts can be defined using Groovy or YAML notation. After building on the producer side, Spring Cloud Contract generates a special JAR file with the stubs suffix, which contains all defined contracts and JSON mappings. Such a JAR file can be built on Jenkins and then published on Artifactory. The contract consumer also uses the same Artifactory server, so they can use the latest version of the stubs file. Because every application expects a different response from person-service, we have to define three different contracts between person-service and a target consumer.

Let’s analyze the sample scenario. Assuming we have performed some changes in the API exposed by person-service and modified contracts on the producer side, we would like to publish them on the shared server. First, we need to verify contracts against the producer (1), and in case of success, publish the artifact with stubs to Artifactory (2). All the pipelines defined for applications that use this contract are able to trigger the build on a new version of the JAR file with stubs (3). Then, the newest version of the contract is verified against the consumer (4). If contract testing fails, the pipeline is able to notify the responsible team about this failure.

1. Pre-Requirements

Before implementing and running any sample, we need to prepare our environment. We need to launch Jenkins and Artifactory servers on the local machine. The most suitable way for this is through Docker containers. Here are the commands required to run these containers.

$ docker run --name artifactory -d -p 8081:8081
$ docker run --name jenkins -d -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts

I don’t know if you are familiar with tools like Artifactory and Jenkins, but after starting them, we need to configure some things. First, you need to initialize Maven repositories for Artifactory. You will be prompted for that just after the first launch. It also automatically adds one remote repository: JCenter Bintray, which is enough for our build. Jenkins also comes with a default set of plugins, which you can install just after the first launch (Install suggested plugins). For this demo, you will also have to install the plugin for integration with Artifactory. If you need more details about Jenkins and Artifactory configuration, you can refer to my older article, How to setup Continuous Delivery environment.

2. Building Contracts

We are beginning contract definition from the producer side application. Producer exposes only one GET /persons/{id} method that returns Person object. Here are the fields contained by Person class.

public class Person { private Integer id; private String firstName; private String lastName; @JsonFormat(pattern = "yyyy-MM-dd") private Date birthDate; private Gender gender; private Contact contact; private Address address; private String accountNo; // ...

The following picture illustrates which fields of the Person object are used by consumers. As you see, some of the fields are shared between consumers, while others are required only by a single consuming application.

Now we can take a look at the contract definition between person-service and bank-service.

import Contract.make { request { method 'GET' urlPath('/persons/1') } response { status OK() body([ id: 1, firstName: 'Piotr', lastName: 'Minkowski', gender: $(regex('(MALE|FEMALE)')), contact: ([ email: $(regex(email())), phoneNo: $(regex('[0-9]{9}$')) ]) ]) headers { contentType(applicationJson()) } }

For comparison, here’s the definition of a contract between person-service and letter-service.

import Contract.make { request { method 'GET' urlPath('/persons/1') } response { status OK() body([ id: 1, firstName: 'Piotr', lastName: 'Minkowski', address: ([ city: $(regex(alphaNumeric())), country: $(regex(alphaNumeric())), postalCode: $(regex('[0-9]{2}-[0-9]{3}')), houseNo: $(regex(positiveInt())), street: $(regex(nonEmpty())) ]) ]) headers { contentType(applicationJson()) } }

3. Implementing Tests on the Producer Side

We have three different contracts assigned to the single endpoint exposed by person-service. We need to publish them in such a way that they are easily available for consumers. In that case, Spring Cloud Contract comes with a handy solution. We may define contracts with a different response for the same request, then choose the appropriate definition on the consumer side. All those contract definitions will be published within the same JAR file. Because we have three consumers we define three different contracts placed in the directories bank-consumer, contact-consumer and letter-consumer.

All the contracts will use a single base test class. To achieve this, we need to provide a fully qualified name of that class for Spring Cloud Contract Verifier plugin in pom.xml.

<plugin> <groupId></groupId> <artifactId>spring-cloud-contract-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <baseClassForTests></baseClassForTests> </configuration>

Here’s the full definition of the base class for our contract tests. We will mock the repository bean with the answer matching the rules created inside the contract files.

@SpringBootTest(webEnvironment = WebEnvironment.DEFINED_PORT)
public abstract class BasePersonContractTest { @Autowired WebApplicationContext context; @MockBean PersonRepository repository; @Before public void setup() { RestAssuredMockMvc.webAppContextSetup(this.context); PersonBuilder builder = new PersonBuilder() .withId(1) .withFirstName("Piotr") .withLastName("Minkowski") .withBirthDate(new Date()) .withAccountNo("1234567890") .withGender(Gender.MALE) .withPhoneNo("500070935") .withCity("Warsaw") .withCountry("Poland") .withHouseNo(200) .withStreet("Al. Jerozolimskie") .withEmail("") .withPostalCode("02-660"); when(repository.findById(1)).thenReturn(; } }

The Spring Cloud Contract Maven plugin visible above is responsible for generating stubs from contract definitions. It is executed during Maven builds after running mvn clean install. The build is performed on Jenkins CI. The Jenkins pipeline is responsible for updating the remote Git repository, building binaries from source code, running automated tests, and finally, publishing the JAR file containing stubs on a remote artifact repository — Artifactory. Here’s the Jenkins pipeline created for the contract producer side (person-service).

node { withMaven(maven:'M3') { stage('Checkout') { git url: '', credentialsId: 'piomin-github', branch: 'master' } stage('Publish') { def server = Artifactory.server 'artifactory' def rtMaven = Artifactory.newMavenBuild() rtMaven.tool = 'M3' rtMaven.resolver server: server, releaseRepo: 'libs-release', snapshotRepo: 'libs-snapshot' rtMaven.deployer server: server, releaseRepo: 'libs-release-local', snapshotRepo: 'libs-snapshot-local' rtMaven.deployer.artifactDeploymentPatterns.addInclude("*stubs*") def buildInfo = pom: 'person-service/pom.xml', goals: 'clean install' rtMaven.deployer.deployArtifacts buildInfo server.publishBuildInfo buildInfo } }

We also need to include the dependency spring-cloud-starter-contract-verifier to the producer app to enable Spring Cloud Contract Verifier.

<dependency> <groupId></groupId> <artifactId>spring-cloud-starter-contract-verifier</artifactId> <scope>test</scope>

4. Implementing Tests on the Consumer Side

To enable Spring Cloud Contract on the consumer side, we need to include the artifact spring-cloud-starter-contract-stub-runner to the project dependencies.

<dependency> <groupId></groupId> <artifactId>spring-cloud-starter-contract-stub-runner</artifactId> <scope>test</scope>

The only thing left is to build a JUnit test, which verifies our contract by calling it through the OpenFeign client. The configuration of that test is provided inside the annotation @AutoConfigureStubRunner. We select the latest version of the person-service stubs artifact by setting + in the version section of the ids parameter. Because we have multiple contracts defined in person-service, we need to choose the right one for the current service by setting the consumer-name parameter. All the contract definitions are downloaded from the Artifactory server, so we set the stubsMode parameter to REMOTE. The address of the Artifactory server has to be set using the repositoryRoot property.

@SpringBootTest(webEnvironment = WebEnvironment.NONE)
@AutoConfigureStubRunner(ids = { ""
}, consumerName = "letter-consumer", stubsPerConsumer = true, stubsMode = StubsMode.REMOTE, repositoryRoot = "")
public class PersonConsumerContractTest { @Autowired private PersonClient personClient; @Test public void verifyPerson() { Person p = personClient.findPersonById(1); Assert.assertNotNull(p); Assert.assertEquals(1, p.getId().intValue()); Assert.assertNotNull(p.getFirstName()); Assert.assertNotNull(p.getLastName()); Assert.assertNotNull(p.getAddress()); Assert.assertNotNull(p.getAddress().getCity()); Assert.assertNotNull(p.getAddress().getCountry()); Assert.assertNotNull(p.getAddress().getPostalCode()); Assert.assertNotNull(p.getAddress().getStreet()); Assert.assertNotEquals(0, p.getAddress().getHouseNo()); } }

Here’s the Feign client implementation responsible for calling the endpoint exposed by person-service

public interface PersonClient { @GetMapping("/persons/{id}") Person findPersonById(@PathVariable("id") Integer id); }

5. Setup of the Continuous Integration Process

We have already defined all the contracts required for our exercise. We have also built a pipeline responsible for building and publishing stubs with contracts on the producer side (person-service). It always publishes the newest version of stubs generated from the source code. Now, our goal is to launch pipelines defined for three consumer applications each time new stubs are published to the Artifactory server by the producer pipeline.

The best solution for this is to trigger a Jenkins build when you deploy an artifact. To achieve this, we use a Jenkins plugin called URLTrigger, which can be configured to watch for changes on a certain URL, in case a REST API endpoint is exposed by Artifactory for the selected repository path.

After installing URLTrigger, we have to enable it for all consumer pipelines. You can configure it to watch for changes in the returned JSON file from the Artifactory File List REST API, accessed via the URI The file maven-metadata.xml will change every time you deploy a new version of the application to Artifactory. We can monitor the change of the response’s content between the last two polls. The last field that has to be filled is Schedule. If you set it to * * * * *, it will poll for a change every minute.

Our three pipelines for consumer applications are ready. The first run finished with success.

If you have already built the person-service application and publish stubs to Artifactory, you will see the following structure in the libs-snapshot-local repository. I have deployed three different versions of the API exposed by person-service. Each time I publish a new version of the contract, all the dependent pipelines are triggered to verify it.

The JAR file with contracts is published under the classifier stubs.

Spring Cloud Contract Stub Runner tries to find the latest version of contracts.

2018-07-04 11:46:53.273 INFO 4185 --- [ main] o.s.c.c.stubrunner.AetherStubDownloader : Desired version is [+] - will try to resolve the latest version
2018-07-04 11:46:54.752 INFO 4185 --- [ main] o.s.c.c.stubrunner.AetherStubDownloader : Resolved version is [1.3-SNAPSHOT]
2018-07-04 11:46:54.823 INFO 4185 --- [ main] o.s.c.c.stubrunner.AetherStubDownloader : Resolved artifact [] to /var/jenkins_home/.m2/repository/pl/piomin/services/person-service/1.3-SNAPSHOT/person-service-1.3-SNAPSHOT-stubs.jar

6. Testing a Change in the Contract

We have already prepared contracts and configured our CI environment. Now, let’s perform a change in the API exposed by person-service. We will just change the name of one field: accountNo to accountNumber.

This change requires a change in the contract definition created on the producer side. If you modify the field name there, person-service will build successfully and a new version of the contract will be published to Artifactory. Because all other pipelines listen for changes in the latest version of JAR files with stubs, the build will be started automatically. The microservices letter-service and contact-service do not use the field accountNo, so their pipelines will not fail. Only the bank-service pipeline reports an error in the contract, as shown on the picture below.

Now, if you were notified about the failed verification of the newest contract version between person-service and bank-service, you can perform the required change on the consumer side.

Original Link

Top Five Books to Learn Spring Boot and Spring Cloud for Java Developers

If you are a Java developer and want to learn more about Spring Boot and Spring Cloud frameworks, you have come to the right place. In the past, I have shared some of the best Spring Boot and Spring Cloud courses. Today, I am going to talk about some of the best books to learn Spring Boot and Spring Cloud. But, before that, let’s try to understand what are microservices and how Spring Boot and Spring Cloud help with the development of microservices in Java. Microservices are nothing but an extension of RESTful web services with the main objective being to break up your code into small, distributed, and independent services for better management. However, it does require a thoughtful design and a significant amount of preparation.

Fortunately, Spring Boot and Spring Cloud simplify your microservice applications by providing common features and allowing you to focus on business logic by abstracting away details required for cloud-based development.

Just like the Spring Framework simplifies Java development, Spring Boot removes the friction and boilerplate code involved with developing a REST-based service.

Similarly, Spring Cloud provides a suite of tools for the discovery, routing, and deployment of microservices to the enterprise and the cloud. This is so that you don’t need to focus on cloud-related details and can keep writing the Java application as you do now.

Since Java development is now moving towards a cloud and microservice world, it’s probably the best time to learn Spring Boot and Spring Cloud, so that you can be ready for great opportunities in the near future.

Best Spring Boot and Spring Cloud Books for Java Programmers

Unfortunately, there are not many good books available on these frameworks, so we don’t have many choices. At the same time, some of the available books are really awesome.

As more and more Java developers are learning Spring Boot and Spring Cloud for developing cloud-based Java applications, you can expect more books to be written and released on these topics. For now, here are some of the best resources for learning Spring Boot and Spring Cloud.

1. Spring Boot in Action

This is the best book to learn Spring Boot from none other than Craig Walls, who has taught most of Java developers’ Spring Framework through his classic book Spring in Action.

Craig has a wonderful ability to explain the complex and tedious concept in simple language with beautiful analogies. Along with that, you will find many beautiful examples in this book as well.

The book covers almost all the essential topics in Spring Boot, starting from auto-configuration and starter dependencies with a general idea of how Spring Boot simplifies Java development.

The book further explores advanced concepts — like the Spring Boot Actuator — to find out what’s going on inside a Spring Boot application. It also looks at the Spring Boot CLI for even simpler Java Spring development with Groovy.

In short, Spring Boot in Action is one of the best books to learn Spring Boot and a must read for any Java developer who wants to master the Spring Boot framework.

2. Cloud Native Java

This is a gem of the book on cloud-based Java development . I don’t think there is any other book that successfully covers the cloud-based Java development and building of a resilient distributed application using Spring, such as this book.

Both authors, Josh Long and Kenny Bastani, are an authority on Spring framework and it shows in this book. The introductions of different aspects of Spring, e.g. MVC, configuration, and cloud, are very good. They have tried their best to keep this complex topic as simple as possible.

In the beginning, cloud terminologies and services may seem overwhelming, but if you stick around and finish the book, you would have to build a strong foundation on building cloud-based Java applications using Spring Boot, Spring Cloud, and Cloud Foundry .

The book is divided into four major sections which covers the basics, developing distributed web services and microservices, data integration and deployment of a cloud-based application into production, and some guidelines on continuous integration and delivery.

In short, this is one of the most comprehensive guides for developing cloud-based Java applications.

3. Spring Microservices in Action

This is another great book on cloud-based Java development, but it focuses on microservices. Actually, this is the first book I read on this topic before starting with Cloud-Native Java.

The author, John Carnell, is a senior cloud engineer with twenty years of experience in Java and it really shows in this book. He has done an excellent job of explaining the key microservices concepts and patterns like configuration, routing, scaling, and deploying your service with real-life examples.

This book will also teach you how to build microservices-based applications using Java and the Spring platform. You will not only learn these concepts, but you will also get hands-on experience with microservices design while you build and deploy your first Spring Cloud application.

Overall, this is an ideal book for Java developers with Spring experience who want to develop microservices applications in Java.

4. Learning Spring Boot 2.0

This is another awesome book for learning Spring Boot 2.0. This is the latest version of the popular Spring Boot framework. The author, Greg Turnquist, is an authority on Spring and works at Pivotal, the company behind the Spring Framework.

He is a member of the Spring Data team and the lead for Spring Session MongoDB. He is also involved with the development of Spring Boot, Spring HATEOAS, and Spring Data REST, while also serving as editor-at-large for Spring’s Getting Started Guide.

All these experiences are apparent in this book. I particularly liked how he explained things in up-to-minor-level-details. For example, in the first Spring Boot examples, he explains what a @SpringBootAppliation is doing in terms of scanning for Spring component recursively, enabling auto-configuration and stating that the class itself can be a source of Spring beans.

He then goes out and explains log and proves his points, which really consolidates the information. The book not only covers Spring Boot, but it also is very rich in testing Spring applications. The author is a bit of a test junky, having written the Python Testing Cookbook.

Learning Spring Boot 2.0 explores the landscape of developing microservices with Spring Boot and deploying the Spring Boot application into production. In short, this is a perfect book to learn Spring Boot for Java developers.

5. Mastering Spring Boot 2.0

This is another relatively new book on Spring Boot by Dinesh Rajput. He is a fellow Java blogger and Spring enthusiast. He is also a Pivotal Certified Spring Professional and the author of Spring 5 Design Patterns, another fantastic book on the Spring framework.

The full title of the book is Mastering Spring Boot 2.0: Build modern, cloud-native, and distributed systems using Spring Boot. As the extended title explains, it also covers Spring Cloud and cloud-based Java development.

In this book, you will start with Spring Boot 2.0, the latest version of the Spring framework and then learn essential features, e.g. auto-configuration, starter dependencies, Actuator, Spring Boot CLI, etc.

Once you are familiar with the basics, you will explore advanced things like customizing auto-configuration to meet your expectation. After that, the book explores the microservice and cloud landscapes by introducing key Spring Boot tools and services.

In short, the book covers everything you need to know for developing Spring-based Java microservices applications, starting from development to testing and deployment.

That’s all for now regarding the best books to learn Spring Boot and Spring Cloud. These are the two  leading Java frameworks for developing cloud-based Java applications. These books will not only help you to learn the basics, but they also gives you the hands-on experience you need to create and deploy your own Java application on cloud.

These books should be enough to learn cloud-based Java development, but if you need more assistance, you can also refer to Master MicroService development with Spring Boot for a more instructor-led learning.

Other Java and Spring Articles you may like:
3 Best Practices Java Devs can Learn from Spring
How Spring MVC works internally in Java?
10 Things Java Developer should learn in 2018?
10 Frameworks Java and Web Developer Should learn
Top 5 Spring Microservice Courses for Java developers
15 Spring Boot Interview Questions for Java developers
10 Tips to become a better Java Programmer in 2018

Thanks for reading this article! If you like these Spring Boot and Spring Cloud books, please share them with your friends and colleagues. If you have any questions or feedback, drop a note in the comments below.

Original Link

Spring Cloud Finchley.RELEASE Is Available

On behalf of the community, I am pleased to announce that the General Availability (RELEASE) of the Spring Cloud Finchley Release Train is now available. The release can be found in Maven Central. You can check out the Finchley release notes for more information.

Lifecycle Announcements for Release Train Versions

The Camden release train has reached end-of-life status. The Dalston release train will reach end-of-life status in December 2018. The Edgware release train will follow the end-of-life cycle of the Spring Boot 1.5.x line.

Notable Changes in the Finchley Release Train

Spring Cloud Function and Spring Cloud Gateway are new additions to the Spring Cloud portfolio. The portfolio was also made compatible with Spring Boot 2.0.x which was a significant effort. Spring Cloud now has a minimum version of Java 8.

Spring Cloud Gateway

Spring Cloud Gateway is an API Gateway built on top of Spring Webflux and Reactor Netty. It is a next generation gateway and can be viewed as a replacement for Spring Cloud Netflix Zuul. It provides dynamic routing based on easy to define predicates. It also provides filters that are scoped to each route, examples include: path rewriting, circuit breaker, adding or removing headers, rate limiting and security. Routes can be defined using properties or using included support for DiscoveryClient (Eureka, Consul & Zookeeper).

Spring Cloud Function

Spring Cloud Function is a project with the following high-level goals:

  • Promote the implementation of business logic via functions.
  • Decouple the development lifecycle of business logic from any specific runtime target so that the same code can run as a web endpoint, a stream processor, or a task.
  • Support a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).
  • Enable Spring Boot features (auto-configuration, dependency injection, metrics) on serverless providers.

Spring Cloud Sleuth

  • Rewritten using Brave #829, migration guide
  • Removed the sleuth-stream#555 and zipkin-stream#727 dependencies. Spans via messaging can be only sent to Zipkin via native Zipkin dependencies.
  • spring.zipkin.sender.type=kafka needs to explicitly be set to send spans over Kafka #985, #1013
  • Added WebClient.Builder support #779
  • Trace tags account for parametrized URL #802
  • Added support for NettyClient instrumentation – allows instrumentation of Spring Cloud Gateway #806
  • Fixed all early bean initialization issues #870
  • Added spring-kafka support #896
  • Added spring-rabbitmq support #883
  • Added support for Apache HttpClient #685
  • Added OpenTracing support #599
  • Added support for AWS X-Ray #459
  • TraceKeys are hidden from the user and are deprecated #940
  • Added support for Dubbo #934


Spring Cloud Config

  • Allow the ability to skip SSL validation for both Git and Vault backends
  • Git backend now has a refresh rate property #749
  • Add support for Gitee webhooks #898

Spring Cloud Netflix

  • Starters deprecated in Edgware have been removed
  • spring-cloud-netflix-hystrix-amqp has been removed
  • ZuulFallbackProvider has been removed and replaced with FallbackProvider#2262
  • / now uses WebFlux #2629
  • Turbine now has a /clusters endpoint that can be used to discover configured clusters #2223
  • Spring Cloud OpenFeign has been moved to its own project
  • Zuul metrics now use Micrometer
  • Turbine Stream support was rewritten to use Spring Webflux.

Spring Cloud Task

Please see the release blog post.

Spring Cloud Commons

  • You can now use the @LoadBalanced annotation on WebClients
  • Retry functionality has been simplified #331

Spring Cloud Contract

  • Added support for RestAssured with RestDocs #334
  • Removed Camel support #386
  • Introduced explicit mode of stubs fetching via stubsMode and contractsMode#287
  • Made @AutoConfigureStubRunner a test slice #473
  • Allows starting multiple versions of the same stub artifact #474
  • Made collection assertion methods more verbose #441
  • Added @StubRunnerPort convenience mechanism of finding stubs #573
  • Allows storing downloaded artifacts after the test got executed #512
  • Added helper methods for HTTP statuses #575
  • Refreshed the documentation #570 and added a 3 seconds & 3 minutes tour #549
  • Bumped WireMock to 2.18.0#659
  • Support for Pact v3 #406 and Pact Broker #191
  • Option to upload and fetch stubs from a Git Repository #596


Spring Cloud Stream

Please see the release blog post.

Spring Cloud Vault

  • Upgrade to Spring Vault 2.0 #203.
  • Auto-configuration for ReactiveVaultOperations to provide a reactive API on top of WebClient#133.
  • Added Reactive Health Indicator #221.
  • Pull, wrapped, and provided modes for AppRole’s RoleId and SecretId authentication identifiers #174.
  • Support for Vault’s generic database backend #169.
  • Retain JSON data types in the backing property source #189.
  • Support for Vault’s versioned Key/Value backend #209.
  • Upgraded Spring Cloud Vault Connectors 2.0.0.RELEASE to Spring Cloud Vault 2.0.0.RELEASE.


Spring Cloud Bus

Actuator endpoints were updated to use the new actuator framework.

Spring Cloud Openfeign

  • Support encoder, decoder, and contract in Feign configuration properties #2687
  • Spring Cloud Cloudfoundry

    The new reactive Cloud Foundry Java Client is used.

    Spring Cloud Consul

    Added support for HTTPS instances and ACLs. @Scheduled is no longer used for Consul watches.

    Spring Cloud Zookeeper

    Updated to use Curator 4.0.1.

    Spring Cloud Aws

    Adds support for PropertySourceLocator that uses AWS Parameter Store. Micrometer support for CloudWatch metrics.

    The following modules were updated as part of Finchley.RELEASE:

    Spring Cloud Consul 2.0.0.RELEASE
    Spring Cloud Gateway 2.0.0.RELEASE
    Spring Cloud Function 1.0.0.RELEASE
    Spring Cloud Zookeeper 2.0.0.RELEASE
    Spring Cloud Sleuth 2.0.0.RELEASE
    Spring Cloud Aws 2.0.0.RELEASE
    Spring Cloud Config 2.0.0.RELEASE
    Spring Cloud Cloudfoundry 2.0.0.RELEASE
    Spring Cloud Security 2.0.0.RELEASE
    Spring Cloud Netflix 2.0.0.RELEASE
    Spring Cloud Task 2.0.0.RELEASE
    Spring Cloud Commons 2.0.0.RELEASE
    Spring Cloud Contract 2.0.0.RELEASE
    Spring Cloud Stream Elmhurst.RELEASE
    Spring Cloud Vault 2.0.0.RELEASE
    Spring Cloud Bus 2.0.0.RELEASE
    Spring Cloud Openfeign


    As always, we welcome feedback on GitHub, on Gitter, on Stack Overflow, or on Twitter.

    To get started with Maven with a BOM (dependency management only):

    <dependencyManagement> <dependencies> <dependency> <groupId></groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Finchley.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies>
    <dependencies> <dependency> <groupId></groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <dependency> <groupId></groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> ...

    or with Gradle:

    buildscript { dependencies { classpath "io.spring.gradle:dependency-management-plugin:1.0.5.RELEASE" }
    } apply plugin: "io.spring.dependency-management" dependencyManagement { imports { mavenBom '' }
    } dependencies { compile '' compile '' ...

Original Link

This Week in Spring: Spring Cloud and JUnit

Hi, Spring fans! Welcome to another wonderful and wild This Week in Spring! This week, I’m in Amsterdam, NL (visiting customers); London, UK (for both the London Java Community Java User Group talk and the SpringOne Tour event); Paris, FR (for the first JHipster Conf); Krakow, PL (for Devoxx Poland), and then it’s off to Sao Paolo, BR (for the Spring Connect show). If you’re in any of those places, say hi!

Original Link

This Week in Spring: TDD, FaaS, Reactor, and GDPR

Hi, Spring fans! Whew! What a wild week it’s been! I landed in Kiev, Ukraine, last Thursday to present at the epic JEEConf in beautiful Kiev. Then, this weekend it was off to Dublin, Ireland and Belfast, North Ireland, where I had the privilege of speaking to some of the amazing Pivotal customers (like Liberty). I concluded today here in Belfast and tomorrow it’s off to bella Barcelona, Spain for the Spring I/O conference.

As usual, it’s been a crazy awesome week in the Spring community so without further ado let’s get to it!

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.


java ,spring ,spring boot ,spring cloud ,jee ,rabbitmq ,news

Original Link

Introduction to Spring Cloud: Config (Part 1)

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, one-time tokens, global locks, leadership election, distributed sessions, and cluster state).

It helps manage the complexity involved in building a distributed system.

In this tutorial series, we’ll be using some of these patterns.


Microservices are a software development architectural style that decomposes the application into a collection of loosely coupled services.

It improves modularity, thus making the application easier to develop, test, and deploy.

It also makes the development process more efficient by parallelizing small teams to work on different services.

There are also various difficulties regarding communication between services, managing configurations, etc. in a microservice architecture.

One should go through the Twelve-Factor App Manifesto to solve many of the problems arising with a Microservice architecture.

Spring Cloud Config

Spring Cloud Config provides server- and client-side support for externalized configuration in a distributed system.

It has two components, the Config Server and the Config Client.

The Config Server is a central place to manage external properties for applications across all environments. We could also version the configuration files using Git. It exposes REST APIs for clients to connect and get the required configuration. We can also leverage Spring Profiles to manage different configuration files for different profiles (environments).

For eg: we may decide to use an embedded H2 in our local dev profile, but use PostgreSQL in our prod profile.

The Config Client binds to the Config Server and initializes Spring Environment with remote property sources.


We’ll use Gradle to build our projects. I recommend using Spring Initializr for bootstrapping your projects.

Config Server

We’ll use:

  • Spring Boot 2
  • Spring Cloud Config Server
buildscript { ext { springBootVersion = '2.0.1.RELEASE' } ...
} ext { springCloudVersion = 'Finchley.M9'
} dependencies { compile('') ...

Config Client

We’ll use:

  • Spring Boot 2
  • Spring Boot Actuator
  • Spring Boot Webflux
  • Spring Cloud Starter Config
buildscript { ext { springBootVersion = '2.0.1.RELEASE' } ...
} ext { springCloudVersion = 'Finchley.M9'
} dependencies { compile('org.springframework.boot:spring-boot-starter-actuator') compile('org.springframework.boot:spring-boot-starter-webflux') compile('') ...


We’ll leave Spring Boot to automatically configure our application based on the dependencies added and the properties specified.

Config Server

public class ConfigServerApplication { public static void main(String[] args) {, args); }

We’ll also have to specify the Git repository where the configurations are stored.

server.port=8888 specifies the Git repository where the configurations are stored.

You can also pass the user credentials to access the Repository by passing the username and password.

Config Client

public class LibraryServiceApplication { public static void main(String[] args) {, args); }
} is used to fetch the correct configuration file from the Git repository. It’s a very important property when used with Spring Cloud projects. We’ll see this later in this tutorial series.

The bootstrap properties are added with higher precedence, hence they cannot be overridden by local configuration. You can read more about it here.


management.endpoints.web.exposure.include=refresh exposes the refresh actuator endpoint. We’ll look at it in a while.


Let’s look at some of the REST APIs that are automatically created to manage and monitor these services.

Config Server

Let’s look at the configuration values for the application libary-service.

curl http://localhost:8888/library-service/default

The output obtained will look like this:

{ "name": "library-service", "profiles": [ "default" ], "label": null, "version": "4df9520f00d65722bf79bfe5ece03c5a18c5c1f1", "state": null, "propertySources": [ { "name": "", "source": { "": "Spring Developers Library" } } ]

It gives details about the Git repository for the configuration files, the configuration values, etc. Here, we can see the value for the property

Config Client

We’ll add a web endpoint that will use the property defined in the configuration in the Git repository.

class LibraryController{ @Value("${}") private String libraryName; @GetMapping("/details") public Mono<String> details(){ return Mono.just(libraryName); }

A Bean marked with the annotation RefreshScope will be recreated when a configuration change occurs and a RefreshScopeRefreshedEvent is triggered.

Whenever a configuration change occurs in the Git repository, we can trigger a RefreshScopeRefreshedEvent by hitting the Spring Boot Actuator Refresh endpoint. The refresh endpoint will have to be enabled.


The cURL command for the Actuator Refresh endpoint:

curl -X POST http://localhost:8080/actuator/refresh \ -H 'content-type: application/json' \ -d '{}'

This will update the configuration values on the Config Client.

We can now check the endpoint and verify if the new configuration value is being reflected or not.

curl http://localhost:8080/details

What if there are multiple instances of the Client running, and we want to refresh the configuration values in all of them?

This can be achieved by using Spring Cloud Bus. It links the nodes of a distributed system with a lightweight message broker. You can read more about it here.


I have tried explaining, with a simple example, how to manage externalized configurations using Spring Cloud Config. In the next tutorial, we’ll look at Service Discovery.

You can find the complete example for the Config Server and Library Service on GitHub.

Original Link

Spring Tips: The Cloud Foundry Java Client [Video]

Hi, Spring fans! In this installment of Spring Tips, we’ll look at the reactive Cloud Foundry Java client. We’ll see how to use it support applications that know how to deploy themselves into a cloud target.

Original Link

Reconfiguring Applications with Spring Cloud Config Server

First we code up a simple Spring Boot 2.0 app and a Spring Cloud Config Server for it to use, doing so quickly by using the Spring Initializr. For this you can code along or clone from GitHub for an ASCII Art Transformers version. Then we dockerize the Config Server so that we can use it in a docker-based project.

Create the Client App

We can quickly create a Spring Boot 2.0 app using the Spring Initializr:

We select these Dependencies as we need our app to be a Config Client, we’re going to have it handle web requests so we add Web and we’ll use the Actuator to refresh config.

After importing this project to our IDE we can add the following class to handle http requests (or get it here):

public class ConfigClientController { @Value("${message}") private String message; @GetMapping public String hello(){ return message; }

It just outputs a message that comes from a property called ‘message’. It’s marked as  @RefreshScope  so that we can later trigger that it should pick up a change to the message property.

In the generated file we add:

message=Hello from application properties

So the message will be ‘Hello from application properties’ and we enable management endpoints (in the Spring Boot 2.0 way; in Boot 1.x we would’ve set We need management endpoints so that we can later perform a refresh.

And in the same directory (src/main/resources) we add a to indicate where it will later find the Config Server and what our application is called (the Config Server will use the name to know which property file to provide):

Now we can start the app by going to its directory and doing ‘mvn spring-boot:run’. Go to localhost:8080 in the browser to see ‘Hello from application properties’. The message comes from the properties file as the Config Server isn’t yet running.

Or in the GitHub version we have ASCII art embedded in the properties file so we instead see:

Image title

(The ASCII art in the file is generated from ascii-art-generator using images from

Create the Config Server

Next we need to create the Config Server. Again we can go to the Spring Initializr:

First we add the  @EnableConfigServer annotation under  @SpringBootApplication on the ConfigserverApplication class.

Then in the generated we add:


This will make the Config Server available on port 8888 (which is the default anyway but it’s nice to be explicit) and tell it to host config files it finds on its own java classpath—we have to use the ‘native’ profile to do that. (For real-life scenarios we’d more likely want to host files from a git repo but we’ll come back to that later.)

Create a file in the same directory (src/main/resources) called ‘’ containing:

message=Hello from configserver

Start the Config Server by running ‘mvn spring-boot:run’ from its directory. Go to http://localhost:8888/configclient/default in the browser and you’ll see that the Config Server is now hosting config.

Refresh the Client App

So the configclient is running and the configserver is hosting config. But localhost:8080 still shows ‘Hello from application properties’.  

We can refresh the client app (in the boot 2.0 way) with:

curl -X POST http://localhost:8080/actuator/refresh

(Note in Spring Boot 1.x the endpoint was http://localhost:8080/refresh. If you don’t have curl you could do an empty POST from postman.)

Now if we go to localhost:8080 again or refresh that page in the browser we see ‘Hello from configserver’. So we can see that the app now after the refresh has used the to find the Config Server and used the config from the server in preference to the values in the

In the GitHub version we have different ASCII Art in the so now we see:

Image title

Dockerizing the Config Server

Using the classpath of the Config Server helped us see everything working quickly but probably isn’t how we want to run in a live system. We’re more likely to want to use a remote git repository. So we’ll want to take out the and lines from the configserver’s as they tell the server to use local files.

We could add a line to set the URI to a GitHub repo containing the file (by setting the But if we’re planning to use Docker we can use relaxed binding so that instead we pass in the environment variable SPRING_CLOUD_CONFIG_SERVER_GIT_URI.

Then we just need to add a Dockerfile to build the image. We can use this:

# requires Docker version 17.05.0-ce-rc1, build 2878a85
FROM maven:3.5-jdk-8 as BUILDCONFIGSERVER COPY src /usr/src/myapp/src
COPY pom.xml /usr/src/myapp
RUN mvn -f /usr/src/myapp/pom.xml clean package -DskipTests FROM openjdk:alpine COPY --from=BUILDCONFIGSERVER /usr/src/myapp/target/*.jar /maven/ CMD java $JAVA_OPTS -jar maven/*.jar

Or just fork this project from GitHub which includes the Dockerfile. We can check this works by doing:

docker build . -t configserver
docker run -it -p 8888:8888 -e SPRING_CLOUD_CONFIG_SERVER_GIT_URI= configserver

And going to http://localhost:8888/bar/default in the browser. (Here is the URI of a sample repo from Spring Cloud containing a

Now that we have an image, we can push the image to a docker registry or create an automated build on dockerhub. Or if you don’t want to maintain an image there are others out there who have created images that are available to use (e.g. ). But if you need to customise the Config Server (say, adding Spring Security) then you’ll want to build the image yourself.

There are much more sophisticated ways of setting up the chain of refreshing the server and refreshing the client’s properties but that’s beyond the scope of this introductory article. To see what more you can do it’s best to read a more in-depth article on using the config server. Or if this has all moved a bit fast then consider a more slow-paced introduction.

Original Link

This Week in Spring: Kafka, Spring Cloud, and Testing

Aloha! This week I’m in sunny Honolulu for the first annual LavaOne conference. If you’re not here, you should be! The show is amazing, enjoys 50% female to male audience attendance, the speakers are world-class (well, except yours truly, but don’t tell them that..), and the location is pretty hard to beat!

That said, nothing gives me more pleasure than saddling up to a table with a laptop, some green tea, sunglasses, and sunscreen and checking in on the community. This week’s been a heckuva week indeed! Lot’s of great stuff so let’s get to it!

Original Link

This Week in Spring: Bootstrapping, Spring Cloud, and Microservices

Hi, Spring fans! Welcome to another installment of This Week in Spring! This week, I’m off to Germany, where I’ll be speaking at the Java User Group in Münster on Wednesday night. Then, it’s off to Solingen for a Cloud Native day on the 12th (this Friday) where I’ll be presenting all afternoon — register now! And, if you’re closer to the Pacific Ocean than the Atlantic Ocean, join me next Monday in Hawaii and we’ll talk about all things Spring at the very promising LavaOne conference.

As usual, we’ve got a lot to cover, so let’s get to it.

Original Link

This Week in Spring: Spring Cloud and Microservices

Hi, Spring fans! Welcome to another installment of This Week in Spring! Can you believe we’re less than six weeks away from 2018? Time sure flies when you’re having fun!

This week I’m in Los Angeles talking to community members and then taking in the Thanksgiving holiday here in the US surrounded by friends and family. Thanksgiving is a chance to reflect on that for which we are thankful. I am sure that I speak for all of us here on the Spring and Pivotal teams when I say that we are thankful for you. Thank you for making this the most amazing, dynamic, exhilarating and interesting community in tech. If you’re in the US, happy Thanksgiving! Either way, we’ve got a lot to cover this week so let’s get to it.

Original Link

This Week in Spring: Spring Cloud and Reactive Streams

Hi, Spring fans and welcome to another installment of This Week in Spring! This week I’m in San Francisco for the first, and sure-to-be-amazing, Kotlin Conf 2017. I’ll be talking about Spring Boot and Kotlin, and I hope you’ll join me if you’re around.

We’ve got a lot to cover this week so let’s get to it!

Original Link