Following the Spring GraphQL project announcement and the availability of a 1.0 milestone, this blog post aims to provide more details.

Introduction

If you’re looking to get started, please head over to our reference documentation and read the “Boot Starter” section, or run the samples.

If you don’t know much about GraphQL, there are plenty of good resources. You can start at graphql.org/learn.

GraphQL is widely adopted and in “Early Majority” based on the InfoQ Architecture Trends for 2020. It provides an alternative to REST APIs that is more focused on data, and provides a schema and a query language for clients to use. The appeal from a client perspective is clear in this State of JavaScript report. You can read GitHub’s story on why it uses GraphQL.

Guest Author: Andi Marek, GraphQL Java founder

I am very happy to announce the creation of the Spring GraphQL project and the availability of an initial milestone towards a 1.0 release. The project integrates GraphQL Java and Spring and was developed in collaboration between both teams.

Today is GraphQL Java’s 6th birthday! One fundamental decision I made from the start was to leave any HTTP and IO aspects as a separate concern. GraphQL Java has always been “just” an engine to execute GraphQL requests. The decision has paid off but the obvious downside is the need to create your own HTTP adapter for real world usage.

The recent Spring Framework 5.3 M1 release announcement mentions “Spring MVC comes with PathPattern parsing for efficient URL matching”. This post expands on that with more context and detail.

Overview

In Spring applications AntPathMatcher is used to identify classpath, file system, remote, and other resources in Spring configuration. It has also been used in Spring MVC to match URL paths. Over time the use of patterns in web applications grew in number and syntax with AntPathMatcher evolving to meet those needs but some pain points remain without a solution:

The following CVE reports were published today:

• CVE-2020-5403 affecting Reactor Netty HttpServer 0.9.3 and 0.9.4.
• CVE-2020-5404 affecting Reactor Netty HttpClient for all 0.8.x and 0.9.x versions in applications where the automatic following of redirects is explicitly enabled.

The fixes are in Reactor Netty 0.9.5 and 0.8.16. If using the reactor-bom, you can upgrade to Dysprosium-SR5 or Californium-SR16.

Reactor Netty is used internally in many frameworks including Spring WebFlux and its WebClient. If you have a Spring Boot application, you can upgrade to Spring Boot 2.2.5 or 2.1.13.

After unfavorable weather on Maven central caused service disruption much of today, skies have finally cleared up, and I am pleased to announce a full round of Spring Framework releases: the 5.2.3 release on the current production branch, along with maintenance branch releases 5.1.13, 5.0.16, and 4.3.26 with selected backports.

Please note that the 5.0.x and 4.3.x lines have reached the end of active maintenance, with just one final wrap-up release expected on each branch before the official EOL date at the end of this year. The 5.1.x line remains active but will be updated less frequently (~ once a quarter) than the 5.2.x line (~ every six weeks) throughout 2020. For more details, please check the 2020 Roadmap blog post. TL;DR: Please upgrade to 5.2+ at your earliest convenience!

The Spring Framework has migrated its entire history of issues from Jira to GitHub. The goal of this blog post is to provide you with context and details about this move.

Migration Details

The entire 15+ year history of every Spring Framework issue, and every comment, has been imported into GitHub. There is a lot to consider in such a move, so let’s take a tour and go over some details.

Links

If you have a link to an existing issue, e.g. https://jira.spring.io/browse/SPR-16751, you’ll be redirected to the corresponding GitHub issue. If you actually mean to go to the Jira issue, append the query parameter redirect=false. On the GitHub side, the imported issue has a link back to its Jira issue origin.

The following CVEs have been published today:

1. CVE-2018-15756 for Spring Framework 5.1.1, 5.0.10, and 4.3.20.
2. CVE-2018-15758 for Spring Security OAuth 2.3.4, 2.2.3, 2.1.3, and 2.0.16.

Please, review the information, including affected project versions, in the CVE reports and upgrade immediately.

Spring Boot Users:
Spring Boot 2.0.6 and 1.5.17, released earlier today, contain the fixes for the above vulnerabilities.

The following CVEs have been published today:

• CVE-2018-1257 for Spring Framework 5.0.6, 4.3.17.
• CVE-2018-1258 for Spring Security 5.0.5.
• CVE-2018-1259 for Spring Data Ingalls SR12, Kay SR7.
• CVE-2018-1260 for Spring Security OAuth 2.3.3, 2.2.2, 2.1.2, 2.0.15.
• CVE-2018-1261 for Spring Integration “Zip” extension 1.0.1.

Please, review the information in the CVE reports and upgrade immediately.

Spring Boot Users: Spring Boot 2.0.2 and 1.5.13, released earlier today, contain the fixes for the above vulnerabilities.

CVE-2018-1270 was reported last week, and unfortunately, was not fully addressed in the 4.3.x branch of the Spring Framework.

A follow-up 4.3.16 version was created and released to Maven Central, and a new CVE-2018-1275 report was published. Please upgrade to 4.3.16 immediately!

Spring Boot 1.5.x Instructions: if impacted by this issue, please upgrade to Spring Boot 1.5.12.

UPDATE 2018-04-09: see follow-up announcement for 4.3.x branch.

Spring Framework 5.0.5 and 4.3.15 (superseded by 4.3.16 with CVE-2018-1275), released earlier this week, include fixes for the following vulnerabilities:

• CVE-2018-1270 –> CVE-2018-1275
• CVE-2018-1271
• CVE-2018-1272

Spring Boot 2.0.1 and 1.5.11 (superseded by 1.5.12 with CVE-2018-1275), that match the above Spring Framework versions, were released today, and are now also available for use.

Please, review the information in the CVE reports and upgrade immediately.