Skip navigation
This project is read only now. Read more.
1 2 3 Previous Next


39 posts

The blog is moving!

Posted by asoldano Dec 17, 2019

The RESTEasy project blog is moving to a new location and this is going to be the last post here.

As you might have noticed, the website (currently hosted on GitHub) has just been updated to include the blog too.


Please keep on following us at

Just before Halloween, here is another nice release of RESTEasy!

The new version comes with:

  • 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


Finally, Quarkus 0.27 has just been released too, and it includes RESTEasy 4.4.0.Final... time to give it a try ;-)

Feedback is welcome as usual!


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.



JakartaEE 8 is here and 9 is being planned these days. When it comes to the Jakarta RESTful Web Services, the spec group is already actively working on version 2.2 and thinking about the following ones. RESTEasy will definitely implement the latest versions on master (we actually have a prototype of the new SE boostrap API ready since months); the backport to 3.x stream will have to be coordinated with WildFly efforts around JakartaEE upgrades.



RESTEasy is implementing MicroProfile REST Client 1.3 and will be updating to new versions should they be produced by the spec working group. Besides that, we have plans for improving the integration of some of the other MicroProfile technologies in RESTEasy (OpenAPI, OpenTracing, Config). The efforts are possibly going to be on both master and 3.x: as Brian recently announced, MicroProfile is going to be a significant focus for the next couple of WildFly releases.


Quarkus integration improvements

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!

Stay tuned ... and keep on contributing!

In release, these dependencies are upgraded:


-  Spring Boot dependency is upgraded to 2.1.9.RELEASE

- RESTEasy dependency is upgraded to version 4.3.1.Final

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!


RESTEasy Spring Boot Starter 4.0.0.Final released



RESTEasy Spring Boot Starter 4.0.0.Final is released and can be fetched from Github:

Here is the maven dependency section to include the new release in your project:




In this release, it uses RESTEasy 4.0.0.Final as dependency.


From this release, the master branch is upgraded to use RESTEasy 4.x as dependency.


The future 3.x releases development will be continued in branch 3.x:


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!

Stay tuned and give the new versions a try!


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!

RESTEasy Spring Boot Starter 3.1.0.Final is released and can be fetched from Github:

Here is the maven dependency section to include the new release in your project:



The change in this release is that it adopts RESTEasy 3.7.0.Final as dependency.

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.


Major cleanup

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:

  1. 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);
  2. 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.


New features

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:

  • in Quarkus, either waiting for next week release or building the latest sources from github master; note, there's a nice quickstart pulling RESTEasy too in the Quarkus Getting Started Guide ;-)
  • standalone, by simply pulling the 4.0.0.CR1 artifacts as dependencies in your Maven project
  • on WildFly 16, by patching its modules (if you can cope with the few API changes we did) with the contents of our jboss-modules module, after having built it from the sources on github.


Hopefully, unless something critical is spotted or reported, we'll be releasing Final (including proper documentation) in few weeks from now.

Stay tuned!

The UndertowJaxrsSpringServer


#undertow #spring


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 addition, the resteasy-spring module contains a default xml configuration file called springmvc-resteasy.xml, and it can be used by default to setup the resteasy-spring component properly.


So users just need to prepare their own spring config file and include the springmvc-resteasy.xml to load the resteasy-spring module. Here is a minimal example of the config:



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 above code is part of the tests in resteasy-undertow-spring, and the tests can be used as usage example:


Resteasy/ at master · resteasy/Resteasy · GitHub


And the tests shows more advanced spring configurations that can be used as reference.

We have removed resteasy-jettison-provider from master branch, and here is the tracker bug on this change:


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:


The above change shows the changes in JAXB annotations after changing the JAXB -> JSON provider to resteasy-jackson2-provider for resteasy-link module.


Above is the summary of Jettison removal.

Filter Blog

By date:
By tag: