Resteasy 3.0.7.Final Released

Leave a comment

Ron fixed a few bugs in validation. Netty improvements. A few other bug fixes here and there.

As usual, follow links from jboss.org/resteasy to download and view documentation and release notes.

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 http://jboss.org/resteasy for how to download the distro and view documentation.

My new book! RESTful Java with JAX-RS 2.0

14 Comments

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 http://jboss.org/resteasy for how to download the distro and view documentation.

Resteasy 3.0.3 Released

Leave a comment

Follow the links at http://jboss.org/resteasy 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 java.net.URL support for JAX-RS 2.0 client framework too.

See http://jboss.org/resteasy 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!

Features

  • 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.

 

 

Resteasy 3.0-RC-1 Release – Test drive before Final!

Leave a comment

Resteasy 3.0-RC1 has been released today.  We are fully TCK compliant now, just need to have Wildfly support HTTP DIGEST auth, then we can officially certify.  RC1 will have a 1 week lifetime and we’ll be doing a 3.0.Final release next week.  So, *LAST CHANCE TO SUBMIT BUGS!*.

Go to: http://jboss.org/resteasy to find the docs and downloads links.

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

Older Entries

Follow

Get every new post delivered to your Inbox.

Join 691 other followers

%d bloggers like this: