Basic Authentication with Java 11 HttpClient
In this article, we will create Java 11 HttpClient that accesses Basic Auth protected REST API resource using sync and async mode. We will use Kotlin for a reference implementation.
Spring Boot 2 based Basic Auth Server
You can directly download the Basic Auth Server from Github Repository and run it locally using the below command.
Starting the server using Gradle
$ ./gradlew bootRun
Server will expose http://localhost:8080/api/health endpoint, which can be tested using the below curl command.
$ curl -i --user admin:password -X GET http://localhost:8080/api/health
Java 11 HttpClient
Java 11 HttpClient supports Basic Authentication using authenticator.
We can use either send or sendAsync api for making synchronous and asynchronous (fully non-blocking) requests.
HttpClient basic authentication — sync client
fun basicAuthSync() {
val httpClient: HttpClient = HttpClient.newBuilder()
.connectTimeout(Duration.ofSeconds(10))
.authenticator(object : Authenticator() {
override fun getPasswordAuthentication(): PasswordAuthentication {
return PasswordAuthentication("admin", "password".toCharArray())
}
})
.version(HttpClient.Version.HTTP_1_1)
.build() val request = HttpRequest.newBuilder()
.GET()
.uri(URI.create("http://localhost:8080/api/health"))
.build() val httpResponse = httpClient.send(request, BodyHandlers.ofString())
println("httpResponse statusCode = ${httpResponse.statusCode()}")
println(httpResponse.body())
}PasswordAuthentication is configured for handling HTTP Basic Authentication.
HttpClient — async client
httpClient.sendAsync(request, BodyHandlers.ofString())
.thenApply(HttpResponse<String>::body)
.thenAccept(System.out::println)
.join()Server Response
httpResponse statusCode = 200
{"status":"UP"}What's new in Spring Boot 2
Spring boot 2 is liberated from legacy baggage of deprecated Java releases. Java 8 is the minimum baseline, with Java 9 support. Under the hood Spring Boot, 2 uses Spring 5.
Reactive web programming support with Spring Webflux.
Auto-configuration and starter POMs for reactive Spring Data Cassandra, MongoDB, Couchbase and Redis.
Supports embedded Netty, along with HTTP/2 support for Tomcat, Undertow, and Jetty
Kotlin we supported in Spring Boot 2, along with Junit 5. Now you can write Spring Boot 2 application from scratch in Kotlin.
A brand new actuator architecture, with support for Spring MVC, WebFlux and Jersey.
Simplified security auto-configuration.
Uses Spring Framework 5 under the hood.
Gradle 4 required, works well with Gradle 5.
Related blog:
Spring boot interview questions
Java 1 1 support from Google App Engine
Google’s App Engine cloud has added official support for Java 11, the latest long-term support (LTS) version of the Java language platform, as a production release.
The App Engine Standard Environment Java 11 runtime is generally available for running any Java 11 application, web framework, or service in a managed serverless environment. Java 11 had been offered on App Engine in a beta release since June.
The Java 11 runtime on App Engine offers twice the amount of memory as the earlier Java 8 runtime, providing better support for applications that run under a heavy workload with large amounts of data. Developers can use frameworks including Spring Boot, Ktor, Vert.x, or Micronaut.
In the Google App Engine managed the environment, the runtime is automatically updated with the latest security patches to the operating system and minor revisions to the Java Development Kit (JDK). App Engine also provides services including request tracing, traffic splitting, centralized logging, and production debugging.
Java 11, or JDK 11, was made available by Oracle in September 2018. As an LTS version, Java 11 is slated to receive support from Oracle well into the next decade. This contrasts with six months of Oracle support for other releases, such as the current JDK 13 release or the prior JDK 12 release.
How to access Google App Engine’s Java 11 runtime
You can access the Google App Engine Java 11 Standard Environment documentation from the Google Cloud website. Google also is offering guidance on migrating App Engine Java 8 applications to App Engine Java 11. You can learn directly from the
Best Java Training in Chennai | Java training Institute
.
How monitoring can kill your Spring Boot 1.x application performance
Any system or application on production without good monitoring should be banned. Monitoring, especially in a large distributed system, is not an option, it’s a must. I hope that this is pretty obvious and I don’t have to explain why. At our company blog, we have been touching this topic many times.
Right now our typical stack for monitoring is Prometheus + Grafana. Prometheus for storing time series data, and Grafana for visualizing them. The last thing missing is that your application should somehow expose metrics for Prometheus scraping mechanism. Usually, this is done by creating some monitoring endpoint with all registered metrics. An obvious approach for business metrics from your application. The problem starts when you want to monitor more low level/technical parameters like JVM metrics (CPU usage, heap usage, GC, etc), Kafka client metrics, Cassandra client metrics, etc. These metrics are already exposed from your code and you can access them via MBeans browser (jvisualvm plugin, or good old jconsole).
Fortunately, there is a tool — JMX exporter, which will automatically create an endpoint with all (or filtered) MBeans data. It’s a very convenient and standardized way of exposing common metrics, especially in the case of complex systems with many microservices. All these data can be represented by useful dashboards in Grafana for JVM monitoring:
Cassandra client:
Kafka producer:
And many other interesting statistics about your application’s behavior.
The problem
What is the problem then? JMX exporter is a very simple piece of software, it just scans all the MBeans and exposes them as Prometheus metrics. The issue with this approach occurs when you’ll use it with a Spring Boot 1.x application (yes, I know that this version will be EOL very soon, but some sad people are still using it). To be precise, when you’ll use Spring Boot Actuator features without caution. The Actuator is a really awesome idea. It provides a lot of useful endpoints for monitoring and debugging your application. If you’re from the Spring ecosystem there is no way that you’re not using it already, usually with default settings…
Imagine a situation, where the performance of one of your applications is very unstable. An HTTP endpoint’s 99th percentile response time should be close to 50ms, but you are observing a lot of spikes to even 300ms. CPU, memory, GC are fine. The load is really low max 10 req/s. All the typical problems with the performance have been checked and everything looks good. Finally, after some profiling, you can spot something interesting.
As it turns out, Spring Boot exposes all Actuator endpoints as MBeans by default, so every 10 seconds Prometheus hits the application endpoint with metrics. Every pull scans all MBeans, and each time one specific MBean is invoked:
Long story short, every 10 seconds, our monitoring infrastructure was invoking a thread dump on our application, which was the root cause of the performance problems. Thread dump generation is a stop-the-world operation in JVM. Very useful for debugging, but clearly shouldn’t be overused.
The solution
After distilling the problem, finding the solution was very easy. Either you can configure the JMX exporter to ignore some MBeans, or you can turn off problematic Actuator endpoint, or you can turn off completely Actuator endpoints as MBeans:
spring.jmx.enabled=false
In some cases, using the JMX exporter might be an overkill. As always — it depends on what you want to achieve. If you just need JVM metrics, you can do this with Prometheus hotspot client only.
Take away
- This issue was already fixed in Spring Boot 2.x, if you are using Spring Boot 1.x check if your Actuator configuration is production ready.
- Learn how to use a JVM profiler, it could be jvisualvm (which is not actually a profiler, but in this case, it was good enough) or Java Mission Control.
- Monitoring is always costly (setup, additional infrastructure, etc) and it will influence your system performance at some level. Usually, this level is irrelevant, but as you’ve just read sometimes it’s worth to check it :)
- Never resign from monitoring, because it will be like driving a car without a speedometer. Sooner or later, you will pay a high price for that.
Related blog:
Spring boot interview questions
Microservices with DevOps Make Changes
Microservice architecture emerged from a common set of DevOps ideologies that came into being at companies like Amazon, Netflix, SoundCloud, Facebook, Google and several others. In many cases, those companies started with monolithic applications, which rapidly evolved into decomposed services, which then communicated via RESTful APIs and other network-based messaging protocols to become the harbingers of a microservices-based architecture.
Yet, the evolution of both microservices and DevOps was not just limited to transforming monolithic applications into decomposed services. Those companies that excelled at DevOps also shared common approaches to software development, had similar organizational structures and development cultures, while also sharing an affinity for cloud-based infrastructure and automation. Companies that have succeeded with microservices have followed a similar progression driven by a desire for development, speed and scalability, all of which fits into the concept of agile development.
The rapid adoption of agile methods also fueled the growth of another concept well supported by a microservices based development cycle, Continuous Integration (CI). Those adopting CI have further leveraged agile ideologies to use microservices as a driver to achieve more frequent software releases, which has led to the practice of continuous delivery (CD). CD uses a quality focused ideology to build potentially shippable product increments, which speeds the deployment pipeline, achieving a result that culminates in bringing changes to production as quickly as possible.
Microservices and DevOps: Creating change together
A microservices-based architecture introduces change, change that is often well received by those creating modern applications. Those embracing that change are finding that productivity is increasing at an astonishing rate and solutions can be delivered much more quickly to those requesting flexible, scalable applications. For those in the field of DevOps fields, microservices bring some significant benefits, including:
- Deployability: Microservices offer increased agility, which fuels the ability to roll out new versions of a service. That agility is due to shorter build, test and deploy cycles. Microservices can also incorporate the flexibility needed to employ service-specific security, replication, persistence and monitoring configurations.
- Reliability: A fault with a microservice only affects that microservice and its consumers. When monolithic applications experience a fault, the entire monolith may fail.
- Availability: Releasing a new version of a particular microservice requires very little downtime, whereas rolling out a new version of a service in the monolithic application normally requires a full restart of the entire monolith.
- Scalability: Microservices can be scaled independently using pools, clusters, grids. That deployment characteristic makes microservices a great match for the elasticity of the cloud.
- Modifiability: Microservices offer the flexibility to consume new frameworks, libraries, data sources and other resources. As loosely coupled, modular components, microservices prove to be easier to work with and support dynamic discovery and binding via a registry.
- Management: Microservices can leverage the agile methodology, where the application development effort is divided across teams that are smaller and work more independently.
Microservices bring additional productivity to DevOps by embracing a common toolset, which can be used for both development and operations. That common toolset establishes common terminology, as well as processes for requirements, dependencies and problems. Which in turn, makes it easier for Devs and Ops to work with one another, allowing those entities to work jointly on a problem and successfully fix a build configuration or build script. DevOps and microservices work better when applied together.
Related blog:
Spring Boot and Microservices
If you were developing web applications 5 or 10 years ago, you would appreciate the advancements in the web apps and microservices space. Microservices architectural pattern has disrupted the way we create applications for the cloud. With the introduction of Spring Boot, the microservices adoption skyrocketed in every sector of the tech landscape.
New Era
Spring Boot 1.0 was released for General Availability by Pivotal on 1st April, 2014. This opinionated framework was created as a need to address the github issue on Spring Framework (which took almost 18 months for the team to release the Spring 1.0 GA version) — Improve support for “containerless” web application architecture, dated Oct 2012.
Microservices has been in the industry for more than a decade and companies like Netflix had adopted them since 2010 (references). Even the 12factor App creator Adam Wiggins started drafting the principles in 2011(references) — these some of the basic principles one would fulfill in creating microservices.
A health Open Source eco-system developed by companies like Pivotal, Netflix and many more., created easy ways for developers to adapt to these technology practices and patterns. Honestly, I got to know about Spring Boot only in 2016 and I have been inspired, amazed and rejuvenated since then; I even started to learn, code and share the same via TechPrimers.
How?
I still remember my first session on Spring Boot by Josh Long, Spring Developer Advocate of Pivotal who is also a contributor to the Spring framework(and it’s bugs — that’s how he addresses himself). His famous phrase,
Make JAR, not WAR
inspired me to start exploring the spring boot’s way of creating microservices and I never stopped exploring the spring ecosystem since then. There are other developer advocates likes Mark Heckler, Matt Stine, etc., and Phil Webb — the creator of Spring Boot, who evangelized the framework to every nook and corner of the tech industry.
In addition to that, platforms like medium.com helped evangelise the developer community with useful explanations, tips, and documentation on microservices architectures and use cases to drive adoption.
Why Spring Boot & Microservices?
With the growing need to create apps as quickly as possible, an opinionated framework like Spring Boot which brings in all the kinds of dependencies right to you is a big win. Adding to the excitement is the Spring Cloud which provides rich libraries for supporting microservices architecture patterns open-sourced by Netflix as part of Netflix OSS to create resilient, scalable and effective communication across microservices. According to me, the main selling point is the developer efficiency in creating microservices with tools like Spring Initializer, Spring Cloud and Spring’s very own annotation based processing.
Not to mention the contribution of Netflix by open sourcing most of its internal frameworks which were used to make microservices ecosystem better with patterns like Hystrix, Eureka, etc., The most unique groundbreaking engineering done by the team is the Chaos Engineering part with their Simian Army.
Future
I’m looking forward to see how Spring Boot counter attack’s the rise of new frameworks like — Micronaut (has faster application boot up using ahead of time compilation), from the developers of Grails framework which takes inspiration from lessons learned over the years building real-world applications from monoliths to microservices using Spring, Spring Boot, and Grails.
Related blog:
Spring Boot and Spring Security Updating
Recently we updated one of our internal applications from Spring Boot 1.5 to 2.1, which includes an update of Spring Security. After the update the OAuth2 security started to fail in the backend, it stopped recognizing the authentication.
Our setup
The project is an Angular 4 application. It uses angular2-oauth2 (1.3) in the frontend, and spring-boot-security and spring-security-oauth2 on the backend. The frontend is responsible for authentication with our Bitbucket account. This information is then sent to the backend via a ‘bearer’ authentication token. We have a separate class extending WebSecurityConfigurerAdapter, annotated with @EnableOAuth2Client, to set our security settings.
Updating the backend
Updating Spring Boot to 2. also includes an update of Spring Security from 4.2 to 5.1. To be up to date with Spring Security OAuth2 we updated it from 2.1.2 to 2.3.4. Upon restarting the application we were faced with an error that there is no bean of type org.springframework.security.oauth2.client.resource.OAuth2ProtectedResourceDetails, which is used to create an OAuth2RestTemplate for communicating with Bitbucket. We found a hint somewhere that we need to add a ClientCrendentialsResourceDetails bean to our project. We did add the bean and now we could start the application. The next problem surfaced quickly: the frontend was still able to authenticate with Bitbucket, but the backend no longer recognized the authenticity token sent by the frontend. Checking against the previous version of the application showed that it used to use a AuthorizationCodeResourceDetails class. We then changed the bean to be of this type. The authentication was still not working.
Is it spring security?
Considering the wide use of Spring Security and OAuth2, we felt that it probably had to do with some specifics in the configuration of our application, or a major change in Spring Security itself. To verify that this was the case we created an empty project, following the first part of the Spring Boot and OAuth2 tutorial. We replaced the OAuth settings with our settings for Bitbucket. Running this application worked! So that means we had to change something in our project.
Updating our security
The main difference between the sample application from the tutorial and our application lies in the use of Spring Security related dependencies, and the tutorial uses a different annotation to enable security. We updated our Spring OAuth2 dependency from org.springframework.security.oauth:spring-security-oauth2 to org.springframework.security.oauth.boot:spring-security-oauth2-autoconfigure and updated our WebSecurity implementation to have the annotation @EnableOAuth2Sso. This got our project in the same state as the tutorial, from a Spring Security perspective. This fixed our issue! We could now login again in the frontend, and the backend recognized the security token again and worked as before. While writing this blog, I did a quick check with the old @EnableOAuth2Client annotation. This also works, so it is not necessary to replace it.
RELATED BLOG:
SPRING BOOT INTERVIEW QUESTIONS
Simple Object Access Protocol Vs. REpresentational State Transfer
SOAP (Simple Object Access Protocol):
SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).
SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data.
WSDL defines contract between client and service and is static by its nature.
SOAP builds an XML based protocol on top of HTTP or sometimes TCP/IP.
SOAP describes functions, and types of data.
SOAP is a successor of XML-RPC and is very similar, but describes a standard way to communicate.
Several programming languages have native support for SOAP, you typically feed it a web service URL and you can call its web service functions without the need of specific code.
Binary data that is sent must be encoded first into a format such as base64 encoded.
Has several protocols and technologies relating to it: WSDL, XSDs, SOAP, WS-Addressing.
REST (REpresentational State Transfer):
Rest is a simple way of sending and receiving data between client and server and it doesn’t have very many standards defined. You can send and receive data as JSON, XML or even plain text. It’s lightweight compared to SOAP.
REST need not be over HTTP but most of my points below will have an HTTP bias.
In case of REST contract between client and service is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It’s highly dynamic unlike WSDL.
REST is very lightweight, it says wait a minute, we don’t need all of this complexity that SOAP created.
Typically uses normal HTTP methods instead of a big XML format describing everything. For example to obtain a resource you use HTTP GET, to put a resource on the server you use HTTP PUT. To delete a resource on the server you use HTTP DELETE.
REST is a very simple in that it uses HTTP GET, POST and PUT methods to update resources on the server.
REST typically is best used with Resource Oriented Architecture (ROA). In this mode of thinking everything is a resource, and you would operate on these resources.
As long as your programming language has an HTTP library, and most do, you can consume a REST HTTP protocol very easily.
Binary data or binary resources can simply be delivered upon their request.
Plain XML or JSON are not RESTful at all. None of them define any controls(i.e. links and link relations, method information, encoding information etc…) which is against REST as far as messages must be self contained and coordinate interaction between agent/client and service.
Related blog:
