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

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.

Scoping out Resteasy Skeleton Key Security

Leave a comment

I’ve been heavily prototyping a security solution for Resteasy code named Resteasy Skeleton Key. The solution has the following requirements:

  • Central auth server
  • Works with browsers.
  • Works with machine clients (code).
  • Single sign-on solution for simple web apps
  • Granting permission to third-parties to access your resources.
  • Maps well to the role-based security model of Java EE
  • Optional client certificate support for increased security
  • Supports SOA.  Distributed applications that have complex interactions between different services.
  • Cloud-ready authentication server/identity server.
  • Integrate tightly and seemlessly to JBoss AS7

 

The Implementation

You can take a look at my code as it progresses.  Here’s generally what I’m doing:

  • OAuth Bearer Token authentication for machine-based clients.
  • Bearer token will be our own extension to Json Web Token (JWT).
  • Bearer tokens will be distributed using  Json Web Signatures (JWS)
  • Bearer tokens are issued for a user and also define role allowed for each distributed resource a user might interact with.
  • OAuth 2.0 and our bearer token implementation will be used to provide browser single-sign-on.
  • Oauth 2.0 and our bearer tokens will be used to provide browser authenticated third-party access grants.  (What OAuth2 was actually designed to do).
  • Client certificates can be  required at any authentication point depending on how you configure things.  Browser to IDP, Browser to resource, client to resource.
  • Implementing an Authentication Server to support all this.

As of 11/21/2012, I have implemented a JAX-RS friendly JWS implementation.  I have speced out and implemented our bearer tokens.  I’ve written a LoginModule for AS7 that can perform OAuth2 Bearer token authentication using our bearer token format and JWS.  Token format allows you to require SSL with client-certificates.  If you have this enabled, it also supports the idea of a surrogate, that is, one principal performat a request on behalf of a specific user.  Finally, I’ve started to scope out and implement an Identity/Authentication server to support all this stuff.  This isn’t complete yet.  I’ll document this stuff in more detail as I get closer to a beta release.

 

Relationship to Picketlink

The plan is to take this prototype and eventually work with the Picketlink project somehow later on.  Either just to funnel requirements, use parts of picketlink, share code, or even have them fully take it over.  The prototype will be fully functional, but will not have many persistence options or a management UI.  There will be a REST management interface though.  Whether or not a UI is introduced will be dependent on what the relationship with Picketlink ends up being.

 

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

<span>%d</span> bloggers like this: