Resteasy 3.0.6 Released

1 Comment

Resteasy 3.0.6.Final has been released today.  This is a maintenance release.  Netty 4 JAX-RS 2.0 Async APIs actually work now!  As usual, check out for how to download the distro and view documentation.

My new book! RESTful Java with JAX-RS 2.0


My 2nd edition of RESTful Java is out!  RESTful Java with JAX-RS 2.0 covers the spec additions to JAX-RS 2.0 including 3 new chapters:

  • JAX-RS 2.0 Client API
  • Asynchronous Client and Server APIs
  • Filters and Interceptors

The book has also been revised here and there to cover some of the smaller features that were added to JAX-RS 2.0 like ParamConverters, Link, an the extensions added to UriBuilder.  The workbook examples and chapters have been revised and expanded to cover this new content as well, so you really get 6 new chapters in total.    Many thanks  to Fernando Nasser, Melanie Yarborough, Meghan Blanchette, Meghan Connolly, and Charlie Roumeliotis for making this happen.  I’d also like to thank the JAX-RS 2.0 JSR Expert Group, especially Marek Potociar, Santiago Pericas-Geertsen, and Sergey Beryozkin.


Resteasy 3.0.4 Released: Netty4, Undertow, JWE, and others

Leave a comment

Resteasy 3.0.4.Final has been released today.  Besides some bug fixes, this ended up being a major feature release specifically:

  • Netty 4 integration thanks to Kristoffer Sjoegren
  • Undertow integration
  • JOSE JSON Web Encryption (JWE) Support
  • A new Servlet 3.0 ServerContainerInitializer for Resteasy.  This allows you to take advantage of JAX-RS integration within a standalone Servlet 3.0 environment.  This means you can work solely with Application classes, use automatic scanning, and not have to write anything in your web.xml files for Tomcat and Jetty deployments!.
  • I also published the new revised examples for my up-and-coming Restful Java With JAX-RS 2.0 book revision.

As usual, check out for how to download the distro and view documentation.

Resteasy 3.0.3 Released

Leave a comment

Follow the links at to download and view release notes.  The was just a maintenance release fixing a few minor bugs in async and cookie parsing.

Resteasy 2.3.7, 3.0.2 Released

1 Comment

Mostly a small maintenance release.  I did add a forward() method to HttpRequest.  If you tried to forward() using a RequestDispatcher, Resteasy would still try and send a response.  The HttpRequest.forward() method makes sure this happens and gives you an abstraction too.  Special thanks to Alexey Ogarkov for adding support for JAX-RS 2.0 client framework too.

See for where to download and view release notes.

Resteasy 3.0 Final Released!

1 Comment

Resteasy 3.0 has been released, follow links on the Resteasy web page to find downloads etc.  After sitting on the JAX-RS 2.0 JSR for two years and implementing it in the Resteasy master branch we’re finally ready to release!  I’d like to first thank the JAX-RS 2.0 JSR especially Marek, Santiago, and Sergey.  We butted heads a lot on the JSR and I could be difficult at times, but I think JAX-RS 2.0 is a great spec because of it. I’d also like to thank Weinan Li, Ron Sigal, and Gunnar Morling for fixing bugs and getting Bean Validation integration working in the last minute.

It is really really really important that you read the migration guide. We had to change a bunch of stuff and behavior because the JAX-RS 2.0 got really strict, specifically the request dispatch algorithm, so you really need to view it.  We also refactored some SPIs and such.  So, again, read the migration guide!


  • JAX-RS 2.0 compliance.  Once Wildfly supports HTTP Digest Authentication we can officially certify Resteasy 3.0.Final.  Since this is really just red tape, I decided to release 3.0 now instead of waiting, weeks for another Wildfly release.
  • SSO and OAuth2 for browser and RESTful web services.  Built to work on AS7 and EAP 6.1, allows you to add these features on top of existing AS7 security domains
  • Bean Validation 1.1. integration support
  • More comprehensive generics support for all component types

Deprecated APIs

JAX-RS 2.0 standardized many features that existed in Resteasy 2.3.x and earlier.  Going forward we will not support these deprecated APIs in Resteasy 3.0.  They are there to ease your migration from proprietary Resteasy APIs to the JAX-RS 2.0 equivalent.  If you have a bug, you need to either provide a patch/pull request yourself, or upgrade to the JAX-RS 2.0 equivalent API.  As soon as Resteasy 3.0 gets into our commercial distribution, we will be removing these deprecated APIs from Resteasy, so you should switch sooner rather than later.

  • Resteasy Client API org.jboss.resteasy.client.ClientRequest etc.  Proxy API has been ported to work on top of JAX-RS 2.0 api.
  • Resteasy interceptor framework: MessageBodyReaderInterceptor, MessageBodyWriterIntereptor, PostProcessorInterceptor, etc… These all have JAX-RS 2.0 equivalents
  • Resteasy async API.  This also has a JAX-RS 2.0 equivalent

What’s Next?

Next few months we’ll be focusing on some point releases to mature 3.0.  I’ll also be finishing a revision of my O’Reilly JAX-RS book and you’ll see some new workbook examples in the distribution soon.  I’m also starting a new project that is going to pull in the OAuth2 work I’ve done.  More on that later though.  As for future Resteasy features, I’m looking for somebody to drive a RESTful database service interface.  If you’re interested, please ping me or our development list.



Java needs dynamic dispatch


I hate JAXB.  I hate Jackson. I hate Hibernate.  I’m sick and tired of writing all these stupid mapping classes for JSON, XML, and ORM.  Wouldn’t it be awesome if you could evaluate JSON and XML the same way Javascript can?  You could if Java supported dynamic dispatch.  Basically the ability to dispatch method invocations and field access dynamically at runtime without compiler checking code.  Dynamic languages like Python, et. al. have always supported this type of feature, and I believe Scala does too.  IMO, it should be as simple as implementing a DynamicDispatch interface

interface DynamicDispatch {
   Object invoke(Class returnType, Type genericReturnType, String methodName, Object... args);
   Object getField(Class type, Type genericType, String fieldName);
   void setField(String filedName, Object value);

This would have a tremendous effect on productivity and maintenance as we could get rid of JSON and XML mapping. I would even say we could do some really innovative things in the ORM space as well.

The poor JAX-RS Request Dispatching Algorithm


As we’re rolling out Resteasy 3.0, we have to pass the JAX-RS TCK.  The good thing about this is that the TCK has grown massively is size and has a lot more test coverage for all old and new features of JAX-RS.  It allowed me to uncover a few bugs I would not have found without the TCK.  An unfortunate downside the TCK also got a lot stricter in some of the weak areas of the JAX-RS specification, particularly the request dispatching algorithm.  I’ll be blunt, the algorithm is poor.  IMO, the old spec leads made a huge mistake in introducing implementation details to the specification and now we have a poor algorithm we are stuck with.  Us vendors cannot innovate and improve it because the TCK has backed us into a corner and the licensing fine print of Java EE makes it really hard for us to ship things that diverge from the spec.  Here are a bunch of problems that used to work in Resteasy, but will no longer work because the TCK tests every fine detail of the JAX-RS matching algorithm.

  •  The @Path annotation at the class level is matched first before matching any resource methods.  Only classes with the best and exact regular expressions are picked.  Then the rest of the request is matched with remaining methods.  So this won’t work anymore with a spec compliant algorithm:
Request: OPTIONS /foo

public class Foo {
   public String get() {...}
public class OptionsDefault {
   public String options() {...}

Earlier versions of Resteasy would match OptionsDefault.options().  Now, this method will not match according to the spec rules and you’ll get the default JAX-RS OPTIONS behavior.

  • Locators are never resolved if there are resource methods that match the request.  For example
PUT /foo/sub

public class Foo {
   public String get() {...}

   public Locator locator() { return new Locator(); }

public class Locator{
   public void put() {...}

You’d think that the request would resolve to Locator.put() but you’d be wrong! Because there is a resource method whose path matches the request, but not the method you’d get a 405 response from the server. What’s interesting if you flip the expressions, a PUT request would work, but a GET request wouldn’t!

PUT /foo/sub

public class Foo {
   public String get() {...}

   public Locator locator() { return new Locator(); }
  • It is possible to have poorer matches
GET /fart
Accept: text/plain

  public String get1() {} 

  public String get2() {} 

  public String get3() {}

You would think that GET /fart would match the get3() method because it is more specific path, but you’d be wrong.  Because get3() has a less specific @Produces get2() would match.  This is weird because the spec originally tells you to sort expressions on a best-match basis but then ditches this information to match Accept headers.

Another related note is the default returned media type.Right now the default is dependent on the deployment.  If there is no Produce header, then the returned media type defaults to a union of the Accept header and explicit media types of all available MessageBodyWriters.  There goes your portability!  Instead, implementations should be allowed to specify their own default or even make it configurable.  But, of course we can’t do that!

Granted some of these issues are edge cases, but IMO, some are not.  The specification has 2 pages on english/pseudo-academic algorithm syntax to describe this very complex, but poor algorithm.  Users will get frustrated trying to understand it.  The experts themselves argued for days on interpretation of the specification.  Users will scratch there head wondering why certain classes will match and some won’t and blame the vendor’s implementation.  Resteasy had at least 4 user-reported regression tests that failed as a result of following the specfication matching algorithm religiously.  I know these users will be back complaining that Resteasy 3.0 does not work for them when Resteasy 2.3.x did.

Resteasy 3.0-beta-3 – Latest Spec Updates

1 Comment

Resteasy 3.0-beta-3 has been released.  Follow the links from our main page to download and view the documentation.  Here are the highlights:

  • The latest and greatest from the master branch of the JAX-RS 2.0 spec.  Many of the client builder SSL changes I introduced in 3.0-beta-2 have made it into the spec.  Thanks Marek for giving the thumbs up on them.
  • There are a few minor features of JAX-RS 2.0 we don’t have implemented yet.  You’ll get a NotImplementedYetExceptoin if you invoke them.

Next I’ll be focusing on my book, implementing our missing features, refactoring, and general test coverage.


Resteasy 3.0-beta-2 Released with New OAuth 2.0 Features


Resteasy 3.0-beta-2 has been released.  Follow the links from our main page to download and view the documentation.  Here are the highlights:

  • Added a new ResteasyClientBuilder class to make it easier to create HTTPS/SSL connections on the client side
  • Extensive work on OAuth 2.0 support including tight AS7 integration.

You can find out more about our OAuth 2.0 stuff here, and the distribution comes with an extensive example.  Here’s the overall features of it:

  • Turn an existing servlet-form-auth-based web application into an OAuth 2.0 provider.
  • Provide Distributed Single-Sign-On (SSO) from a central authentication server. Log in once, and you can securely access any browser-based app configured to work in the domain.
  • Provide Distributed Logout. Following one link from any application can log you out of all your distributed applications configured to use SSO.
  • Web apps can interact securely with any remote restful service by forwarding access tokens through the standard Authorization header.
  • Access tokens are digitally signed by the oauth2 framework and can be used to access any service configured to work in the domain. The tokens contain both identity and role mapping information. Because they are digitally signed, there’s no need to overload the central authentication server with each request to verify identity and to determine permissions.

What’s next for Resteasy?  Next release I’ll be focusing on getting it up to date with the latest JAX-RS 2.0 snapshot.  I also have to get started on my O’Reilly book.

Older Entries Newer Entries

%d bloggers like this: