The poor JAX-RS Request Dispatching Algorithm

5 Comments

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

@Path("/foo")
public class Foo {
   @GET
   public String get() {...}
}
@Path("/{.*}")
public class OptionsDefault {
   @OPTIONS
   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

@Path("/foo")
public class Foo {
   @GET
   @Path("sub")
   public String get() {...}

   @Path("{id}")
   public Locator locator() { return new Locator(); }
}

public class Locator{
   @PUT
   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

@Path("/foo")
public class Foo {
   @GET
   @Path("{id}")
   public String get() {...}

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

  @GET
  @PATH("foo") 
  @Produces("text/plain") 
  public String get1() {} 

  @GET
  @Path("{text}") 
  @Produces("text/plain") 
  public String get2() {} 

  @GET
  @Path("f{text}") 
  @Produces("text/*") 
  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-5 Released

5 Comments

Did a bit of refactoring of the SPIs to improve generics support among other bug fixes.  A side effect to this is that there is now a programmatic interface that allows you to register un-annotated resource classes.  Also, bumped Jackson to 1.9.12 and also added an additional Jackson2 provider.  See docs for more details.

http://jboss.org/resteasy

Resteasy 3.0-beta-4 and 2.3.6.Final Released

1 Comment

See jboss.org/resteasy for relevant links for downloads/documentation.

3.0-beta-4 is our last beta!  Everything should be implemented.  JAX-RS 2.0 Final is being voted on in the JCP.  We’ll be obtaining the TCK soon and starting work on getting certified.  There’s also some architectural work that needs to be finished for 3.0.  We’ll have a short RC release sometime in May, then a 3.0 Final Release early June.

2.3.6 is just a maintenance release.

Resteasy 3.0-beta-3 – Latest Spec Updates

1 Comment

Resteasy 3.0-beta-3 has been released.  Follow the links from our main jboss.org 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

3 Comments

Resteasy 3.0-beta-2 has been released.  Follow the links from our main jboss.org 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.

Resteasy 3.0 Beta 1, JAX-RS 2.0 Preview

4 Comments

Now that JAX-RS 2.0 is in Public Draft and has stabilized a bit, API-wise, we finally released Resteasy 3.0 Beta 1.  This release implements almost all of the features defined in the JAX-RS 2.0 Public Draft.  Many of the key features in Resteasy 2.x have now been standardized in JAX-RS 2.0.  There’s a new client API which is similar (actually better) than the current Resteasy 2.x client API.  Interceptors have been added to the spec.  You’ll find that they map very closely to Resteasy’s.  I pushed really hard for this.  Finally, there’s the async HTTP apis.  Also very similar to Resteasy’s.  All and all, if you’re using some of these features currently within Resteasy, you shouldn’t have much problems migrating to the JAX-RS 2.0 equivalent APIs.  The only thing we’re missing is the client proxy support, but I couldn’t get other experts to agree it was a good idea to add. 😦

This beta has a few JAX-RS 2.0 examples with the distribution.  The Resteasy documentation regarding JAX-RS 2.0 isn’t where I want it yet, but we’ll get there as we get closer to a final release of 3.0.  To learn some of the new features, it may be best to take a look at some of the features within Resteasy that take advantage of these APIs.  I’ve linked them all below.

java.dzone.com/articles/whats-new-jax-rs-20

Resteasy 2.3.5 Released

2 Comments

After a bit of delay, Resteasy 2.3.5 is finally out.  It is pretty much a maintenance release.  I want to thank Ron Sigal and Wei Nan Li.  They did almost all the work for this release (minus patches submitted by users).  Resteasy 3.0 beta later this week!

Go to Resteasy website for links on how to download, you can check out the release notes too.

Older Entries Newer Entries

%d bloggers like this: