a bunch of new features in the Spring Web integration area
many enhancements, mainly aiming at improving performances
a lot of component upgrades, to pull in the latest / greatest available dependencies
some important bug fixes (including one for a potential memory leak in the Reactor Netty client integration)
In addition to that, RESTEasy 4.4.0.Final is the first version relying directly or indirectly on Jakarta EE API artifacts. We've been replacing all JavaEE API dependencies with the corresponding Jakarta EE 8 ones, while moving to new major versions of JBoss spec API artifacts (now forked from Jakarta EE APIs). This basically followed the same approach we used in WildFly (read more from Brian here, if interested).
The 4.4.0.Final release artifacts are available on Maven Central and JBoss Nexus repositories as usual and the distribution can also be downloaded at https://resteasy.github.io/.
If you look at the download page, you might notice that so far 2019 has been a year rich of RESTEasy releases. We've made 11 new versions available to the community, starting a new major (4.0) and six new minor (3.7, 3.8, 3.9, 4.1, 4.2, 4.3) streams. This was partially because we're trying to avoid including features in micro version releases and we're carefully ensuring that anything that is backported to RESTEasy 3 is fully backward compatible, so that it can be consumed by WildFly. The other reason for the high number of minor releases... is basically that we've got a lot of good quality contributions from the community! Thanks!
As the releases have been somehow unpredictable, I wanted to write down and share a development roadmap, but these days that's quite a difficult task, especially considering that now RESTEasy is looking at both JakartaEE and Microprofile evolution (which is far from being set in stone ;-)), while both WildFly and Quarkus are feeding RESTEasy's requirements tracking list and begging for frequent releases ;-) So I think I'll start with providing some highlights on the areas where the core team is currently willing to focus in the next 12-18 months; clearly I expect the community to influence the actual future of the project.
I foresee multiple contributions and request for enhancements coming from the Quarkus land in the very next future. A few examples of possible improvements would be the support for non-blocking IO on server side and possibly an abstraction layer for the access to annotations, to avoid RESTEasy performing a lot of annotation scanning at runtime.
WildFly integration improvements
In addition to the JakartaEE and MicroProfile efforts mentioned above, we still have a few new features that were planned for previous WildFly releases but haven't been completed yet. I'm thinking about exposing statistics for RESTEasy resources in the WildFly management model and possibly adding a new module for WADL support.
That's it for now, I promise I will try to update you on the plans in the future!
Two new RESTEasy releases appeared recently, 4.3.0.Final and 3.9.0.Final. Both of them introduce a new feature which allows resource method parameters to be java.util.Optional<T> types, allowing a cleaner coding style. Like the previous 4.2.0.Final release, 4.3.0.Final includes performance improvement contributions from the community, and, of course, they both have bug fixes (upgrade early and often!) and component upgrades. 3.9.0.Final is the latest in the succession of releases targeted towards Wildfly, and it will ship with the upcoming Wildfly 18. 4.3.0.Final is targeted towards the next Quarkus release.
The RESTEasy Spring Boot Starter 4.1.0.Final and 3.2.0.Final are released, and the major change is that these two releases adopt the newest RESTEasy releases as dependencies (RESTEasy 4.3.0.Final and 3.9.0.Final respectively for each branches).
The latest artifacts are available on the JBoss Nexus repository as well as Maven Central repository.
I'm pleased to announce that, at the end of last week, RESTEasy 4.2.0.Final has been released! It's less than two months since the previous minor has been tagged, however the community has been quite active lately (thanks!!) and we had a few interesting contributions really deserving a release:
Great performance improvements: two parallel efforts on reducing memory footprint improved our internal benchmark numbers quite a lot; both JAX-RS client and server applications should be sensible faster as a consequence of a lower memory allocation rate. Moreover, a couple of nasty bugs resulting in performance penalties in some corner cases have been fixed.
Vert.x Client HTTP engine: we now have another implementation of the RESTEasy Client HTTP engine interface, based on Eclipse Vert.x and properly supporting async / non-blocking IO.
Spring Web REST integration (experimental): RESTEasy now provides the ability to process Spring Web REST annotations (i.e. Spring classes annotated with @RestController) and handles related REST requests without delegating to Spring MVC.
The latest artifacts are available on the JBoss Nexus repository as well as Maven Central repository. Quarkus is being upgraded as well to benefit from the latest additions mentioned above!
as previously anticipated, RESTEasy 4.1.0.Final has been released! It brings the new MicroProfile REST Client 1.3 implementation on 4.x series too, the same provided last week with 3.8.0.Final.
Besides that, few other new features and improvements are included in this release; something worth mentioning is that the community contributed two new modules for integration with the Project Reactor , namely a new implementation of the Async client engine interface based on Reactor Netty and initial support for Flux and Mono types in resources, similarly to what RESTEasy already does with RxJava 2 types.
While 3.8.0.Final is soon landing in WildFly and Thorntail, the upgrade to 4.1.0.Final has just been merged in Quarkus master, so the new version will most likely be part of next Quarkus release!
Last week the release of MicroProfile 3.0 was announced. It comes with few additions and updates in some of its specifications, one of them being the MP REST Client which has been upgraded to version 1.3.
RESTEasy used to implement an old version (1.0) of MP REST Client, while more recent versions have been provided as part of the SmallRye project. Starting from MP 3, we decided to join the efforts of the two teams and provide the most up to date version of that spec in RESTEasy.
So today I'm happy to announce the availability of RESTEasy 3.8.0.Final, whose main new feature is the implementation of MicroProfile REST Client 1.3. The artifacts have been built and released to both Central and JBoss Nexus Maven repositories. The new documentation as well as the binaries, are available on the website.
A new release from the 4.x stream is also coming very soon and will of course include the same MP REST Client 1.3 implementation too.
Stay tuned and try RESTEasy 3.8... feedback is welcome!
At the end of March I was announcing RESTEasy 4 CR1 and telling the final was coming soon. Unfortunately it has taken more than I hoped for the transition; the nice thing, however, is that was because the community (especially Quarkus one) really tested the CRs and we got few bugs reported (and fixed ;-) ). In any case earlier today the 4.0.0.Final artifacts have been built and released to both Central and JBoss Nexus Maven repositories. The new documentation, as well as the binaries, are available on the website.
Previous blog posts already provided references to the new features coming with RESTEasy 4, I really encourage reading them.
Going beyond new features, I believe this release sets the ground for future exciting developments in RESTEasy; the project got rid of old / deprecated pieces and is in a better position for accomodating the implementation of new and modern features, especially for Quarkus cloud-related scenarios.
Stay tuned and try RESTEasy 4... feedback is welcome!
Earlier this week a release candidate version (4.0.0.CR1) of RESTEasy has been tagged. The artifacts are built and available on the Maven Central and JBoss Nexus repositories.
This is the result of many months of work on RESTEasy master branch in parallel with the continuous enhancements and maintenance on the 3.x stream ; below I'm highligthing some of the areas on which the team has been focussing.
During last 2 years, we have spent a lot of energies in getting rid of not-needed anymore (or deprecated) classes, components, dependencies and such. As an example, RESTEasy 3 still included the old RESTEasy 2 client implementation pre-dating the JAX-RS 2 spec client; clearly, that's deprecated since years and possibly even confusing users; with RESTEasy 4 it's gone. Similarly, old and deprecated modules have been dropped, including:
the Jettison, Jackson 1 (org.codehaus one), Abdera and YAML providers
the Netty 3 server adapter
the RxJava (1) integration
the TJWS embedded server
few security modules duplicating Keycloak services.
Code restructure and optimizations
Together with the removal of old cruft, we've made some progress in restructuring the project in a way that:
allows running with JDK9+ (JDK11 tested at the time of writing) and the JPMS module system (as an example, we had multiple packages split between different modules that had to be dealt with);
allows clearly figuring out whether a given class is to be considered as part of RESTEasy public API or not.
This clearly resulted in a lot of refactoring, with some classes that had to be moved. We tried to cause as less disruption as possible with the changes, still few non-backward compatible changes had to be performed and are going to be documented in a migration guide to be prepared before releasing 4.0.0.Final. Regarding the second goal above, the big resteasy-jaxrs and resteasy-client modules have been split into resteasy-core-spi, resteasy-client-api, resteasy-core and resteasy-client, with the first and second ones to be considered as public modules, for which we're expected to retain backward compatibility till next major release.
The reason for the refactoring aimed at the public/private module separation is of course easier future maintenance; however, we also did some refactoring for optimizing few parts of the project that we knew as problematic performance-wise. That's the case of the ResteasyProviderFactory class, which has grown a lot year after year and had a lot of state info being copied over and over for most common usage scenarios, badly increasing memory pressure. In RESTeasy 4, when a ResteasyProviderFactory instance is known to be needed for client usage only, the server side specific data is not computed and stored; the opposite happening for server-side only scenarios, with a nice memory allocation reduction.
RESTEasy 4 is coming with all the features, fixes and upgrades that went into the 3.x releases (350+ jira issues have been solved). To name some of the recent additions, that includes the JAX-RS 2.1 implementation, the Reactive programming support, the new HTTP client engines (including NIO), etc.
On top of that, there're few additions that could not be backported to 3.x branches and are new in RESTEasy 4:
While RESTEasy 3 main integration targets are WildFly and JBoss EAP 7.x, when the efforts for RESTEasy 4 were started we had no clear idea of which container would have been consuming the project, so we thought we would have targeted standalone usage of RESTEasy. The reason for that clearly were WildFly and JBoss EAP coming with strict rules around backward compatibility and RESTEasy 4 not being able to satisfy them (because of the changes explained above and considering his historical deficiencies in terms of public/private classes separation).
However, when the work on Protean (now Quarkus) started, it became evident that RESTEasy 4 was well positioned for being included in the new stack, especially considering our efforts on reducing the memory footprint and getting rid of useless / old classes while retaining modern functionalities like the reactive programming support. As a consequence, Quarkus has been launched including RESTEasy 4 beta and few days ago I've upgraded it to pull 4.0.0.CR1.
So, it's definitely time to give RESTEasy 4 CR1 a try! There're multiple ways you can play with it:
Recently I’m working on migrating resteasy-spring tests to use the Undertow container. Before these tests were using the TJWS embedded container.
As resteasy-tjws container is deprecated in master, so there is some work to be done to make undertow container to load the resteasy-spring components correctly.
In order to achieve the goal, I created a new module called resteasy-undertow-spring, and it contains a single class called UndertowJaxrsSpringServer.
This server class will accept the spring xml configuration file, and load the configured spring context beans into spring provided org.springframework.web.servlet.DispatcherServlet. Here is the relative code in UndertowJaxrsSpringServer:
In above config, we can see it includes the springmvc-resteasy.xml provided by resteasy-spring module, and it will scan the org.jboss.resteasy.springmvc.test package to include the user-written jaxrs resources.
And here is the code to setup the UndertowJaxrsSpringServer and start it:
The major affect is that the resteasy-link module is now dependent on resteasy-jackson2-provider to replace resteasy-jettison-provider to support JAXB annotation -> JSON data marshaling.
In addition, Jackson2 has some subtle differences on supporting JAXB annotations comparing with the default JAXB or Jettison marshallers. So some resteasy-link test classes are adjusted to accommodate this change. Here is the relative PR that shows the difference after the migration: