The JavaOne 2010 presentation "Advanced Java API for RESTful Web Services (JAX-RS)" was advertised as "Full" and that turned out to be the case. Some attendees arrived as late as ten to fifteen minutes after the start, which was obviously not a good idea for such a popular session. It was standing-room-only for this presentation. Paul Sandoz and Roberto Chinnici alternated in presenting. I'll refer to them interchangeably here as "they" to avoid the likely mixing up of their names.
JAX-RS is the next release in the JSR-311 specification. JAX-RS 1.1 is part of Java EE 6, but is not (seemingly inexplicably) part of the Web profile. The main purpose of JAX-RS 1.1 is to integrate with other Java EE 6 technologies. They listed seven implementations of JAX-RS: Jersey (reference implementation), Apache CXF, Apache Wink, eXo, RESTEasy, Restlet, Triaxrs.
After a brief "bootstrap" review of JAX-RS, they went into runtime resource resolution.
A section of this presentation was devoted to integration with CDI (JSR 299). When using EJBs with CDI, the general rule is to "annotate with @Path to convert class of a managed component into a root resource." The presenters also had a bullet emphasizing that "Root resource classes need to be annotated with CDI scope to become CDI managed." This step is necessary due to slightly different models between CDI and JAX-RS. They demonstrated the steps necessary to convert to a CDI resource, including use of the @Inject annotation. Normal JAX-RS classes may not work properly with CDI; need to use the steps they outlined instead.
Another topic covered in this presentation was runtime content negotiation. A convenient approach for this in JAX-RS uses the Variant builder class.
One of the sections of this presentation that I found most interesting was that which covered handling of generic type erasure. The speakers and their slides apologized many times for JAX-RS's and Java's erasure of generic parameterized types. They showed that type is retained when returned in collection directly, but is lost inside a Response object. The work-around is to use GenericEntity with a method-less implementation. There is talk of JAX-RS 2 providing a JResponse, but will still need to use verbose syntax like JResponse.<List<bean>>. This is probably the best that can be done until we have Java runtime generics reification.
The presenters discussed one of my favorite things about JAX-RS: its elegant handling of exception mapping. They demonstrated that, without mapping, the web container provides a 500 HTTP status code for runtime exceptions. They pointed out that a web application's error page can be used to handle these. Checked exceptions also propagate through, but are wrapped in ServletExcepton. They showed how the exceptions can be mapped to specific HTTP status codes and associated descriptive text instead of the normal Java stack trace.
Before ending this post, I have some general observations. I was not surprised to see the speakers use Curl as a command-line demonstrator in some of their JAX-RS demonstrations. I was also not surprised that this was a popular session with a waiting line and was almost completely filled to capacity. The presentation included a lot of code and demonstrations. Although I had read about and even used several of the covered topics, it was nice to see them all presented again in an organized fashion and to hear from people who live this stuff. I was especially happy to see that someone else was as bothered by lack of Java runtime generic reification as I am.
No comments:
Post a Comment