Thursday Feb 26, 2015

Jersey, from Android to Mainframe

As usual, the Jersey Team is busy cranking out new releases. In February, the team has released Jersey 2.16 (release notes, change log) and Jersey 1.19 (blogchange log).

Jersey has a large, active and involved community. For example, there was a bug in Jersey when used on z/OS (who doesn't use Jersey on z/OS?). A community member raised this particular issue along with a suggested fix, fix which has been integrated in 2.16.

Jersey 2.16 is also solving some of the issues related to running the Jersey client stack on Android. Supporting Android is more a side project and Jersey 2.16 clearly shows some initial success. But more work needs to be done. The Jersey Team is looking for concrete feedback on real uses-cases and why not, community contributions too.

So with 2.16, you can finally run a Jersey client on an Android phone connecting to a Jersey server running on Z/OS! Yeah!

And it's not because the Jersey community is already large and active that you cannot participate, contributions are always welcome! See here on the different ways to contribute to Jersey.

Thursday Jan 29, 2015

Using Jersey Client with Netflix Hystrix

There are lot of discussions about Microservice architecture. Lot of them are focused mostly on the benefits of Microservices; sometime some of the drawbacks are overlooked. I am not going to start another discussion on this but one thing is clear: as soon as you have multiple services, you should expect that some of them will fail at some point. Failure is almost inevitable!

Your infrastructure has to be designed with service failure (and degradation) in mind because you don't want all your services to be unavailable just because one of the underlying service is down (or just very slow). Your application needs to be able to isolate any potential failure and offers, at any time, some sort of graceful degradation. The overall idea is to introduce intelligence at the end point level to cope with such issue. You need a circuit breaker to avoid cascading failure. 

Netflix Hystrix is one of the popular solutions for introducing those circuit breaking capabilities. Hystrix is a latency and fault tolerance library designed to isolate points of access to remote services. In case of failure, Hystrix can stop cascading failure and enable resilience in distributed systems. Libor Kramolis from the Jersey Team has just published an article showing how to use the new Jersey Client Reactive API with Netflix Hystrix (and RxJava Observable).

Tuesday Jan 13, 2015

Reactive Jersey Client

One of the common problems of synchronous applications is that they are not using resources in an efficient manner. In a synchronous application, it often happens, for example, that threads are blocked waiting for something to happen.  That is clearly not efficient!  On the other hand, asynchronous applications allows to better utilize those threads but this often comes at a price as it is not that easy to write (complex) asynchronous applications.  Writing asynchronous applications involve having to deal with nested callbacks, the famous "callback hell".  And if the level of nested callbacks is too deep, it can also be very tricky to properly handle errors within the application, etc.

Reactive programming is a popular paradigm used to develop more easily asynchronous applications; it is based around data flows and changes propagations.  This Reactive approach also leads to be more maintainable too as the code is easier to write and understand.

Michal Gajdos of the Jersey Team has just written a series of posts introducing the 'Reactive Jersey Client API', a new generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. 

Thursday Nov 06, 2014

JavaOne Replay: JAX-RS.next

JAX-RS is a key technology of the Java EE platform as REST endpoints are more and more used. Marek Potočiar (JAX-RS Co-Specification Lead) did a session during JavaOne to detail some of the proposed JAX-RS enhancements and extensions that should be part of Java EE 8. These proposals include better support for JSON (JSON-B), improved alignment between JAX-RS and CDI, enhanced support for hypermedia as well as declarative security, server-sent events, and MVC integration. 

Jersey is the open source JAX-RS Reference Implementation but Jersey doesn't limit itself to the specification, i.e. Jersey has also has additional specific features. In some cases, some of the Jersey proprietary features have been standardised and added to the specification (eg. the Client API have been added to JAX-RS 2.0). So it is always interesting to check the Jersey specific extensions as some of those might be potential candidates for inclusion into a future revision of the JAX-RS specification. For example, SSE is currently supported in a Jersey specific manner but the plan is to standardised SSE support in JAX-RS 2.1. So make sure to also watch this 'What's New and Noteworthy in Jersey 2' replay that was presented by Jakub Podlešák and Miroslav Fuksa during JavaOne 2014.

You can get the 'Let’s Talk JAX-RS.next!' slides here.

Friday Sep 12, 2014

JSR 370: Java API for RESTful Web Services 2.1

A proposal for JAX-RS 2.1 has been recently submitted to the JCP, this news was a bit overshadowed by the Java EE 8 Platform submission announcement but it is also important. It is important as JAX-RS is a significant technology of the the Java EE Platform but JAX-RS is also very relevant outside of the platform. It is not uncommon to see more specific RESTful based applications built upon a standalone JAX-RS implementation. And with the Client API introduced in JAX-RS 2.0, JAX-RS is also getting more and more relevant in the client space.

JAX-RS 2.1 (JSR 370) has now entered the JSR Review Ballot for a 2 weeks period (ends on September 22). The proposed scope of JAX-RS 2.1 currently includes :

  • Adding support for Server-Sent Events
  • Improving integration with CDI
  • Exploring support for non-blocking I/O in providers (filters, interceptors, etc.)
  • Evaluating ways in which declarative security can be supported
  • Providing integration with JSON-B
  • Making JAXB conditional on runtimes where it is available
  • Building upon the hypermedia API introduced in version 2.0
  • Investigating the reactive programming paradigm as a way to improve the JAX-RS asynchronous client API
  • Evaluating any requirements necessary to support the use of JAX-RS resource classes as controllers in the MVC 1.0 JSR

Even tough JAX-RS 2.1 will be a 'minor' release; its current scope is quite large in terms of added features!

And if you are attending JavaOne, here are a few JAX-RS related sessions that you should consider attending :

Tuesday Jun 17, 2014

Jersey OAuth support

"The biggest guru-mantra is: never share your secrets with anybody. It will destroy you." (Chanakya

You have probably already heard of OAuth as it is widely used by many online services providers such as Google, FaceBook, LinkedIn, Yahoo, Twitter, ... to name just a few! OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password.  

OAuth support was introduced, several years ago, in Jersey 1.x. 'Recently' ... well more than 6 months ago (*), OAuth support has been added to Jersey 2.x, this post post covers in more details the OAuth support added to Jersey 2.3

If you are not yet familiar with OAuth, it is probably a good time to start to look at this open protocol. The OAuth chapter of the Jersey documentation should be a good starting point.

(*) It's sometime difficult to keep up with the Jersey release cadence! At the time of writing, the current release is Jersey 2.9!

Wednesday Apr 16, 2014

JSON Schema

We often tends to compare JSON against XML, i.e. JSON is simple, XML is not so simple. JSON is light, XML is heavyweight, etc. But there are still reasons to prefer, in certain cases, XML over JSON : e.g. transformation capability, XML extensibility, validation, ...

A question I sometime get when I talk about JSON-P support in Java EE is what about Schema? The works around JSON Schema standardisation is progressing but right now, this is still a draft specification. Nevertheless, this is something that you can already start to use. For example, this post shows how-to generate JSON Schema with Eclipse Link MOXy today.

As said earlier, the JSON Schema space is evolving, there are works that needs to be done at various levels but we can expect, over-time, an improved support for JSON Schema in the Java ecosystem. 

Friday Jan 31, 2014

JAX-RS Managed Clients in Jersey

As you probably know, JAX-RS 2/Java EE 7 now includes a brand new standard client API. If you don't know about it yet, you should check out this excellent blog entry by Mohamed Sanaulla now :-). The standard client API uses the factory/builder patterns and not injection. This makes it very well suited for Java SE based environments such as JUnit tests and JavaFX UIs. However Jersey, the JAX-RS 2 reference implemention included in GlassFish 4 goes much further by providing a managed JAX-RS client that makes full use of injection. This is ideal for server-side mash-ups and system-to-system/machine-to-machine communication.

Michal Gajdos of the Jersey team does an excellent job of explaining the API details in this code-driven blog entry. You can also check out the code on GitHub and running example on Heroku!

Tuesday Jan 28, 2014

Using updated release of Jersey, Tyrus, Weld, ... in GlassFish 4

The Java EE specification is an umbrella specification that refers to different components specifications, aka components JSRs (e.g. Servlet, JMS, JAX-RS, ...). And as the Java EE 7 Reference Implementation, GlassFish 4 is made of those different components JSRs Reference Implementations. 

In addition to the specification, most of those implementations (eg. Jersey) also offers additional features (and fixes). And clearly, the different implementations that make GlassFish are evolving each at a different pace. Jersey (JAX-RS RI), Tyrus (WebSocket RI), Weld (CDI RI), Mojarra (JSF RI) are examples of implementations that evolves rapidly. GlassFish 4.0 embeds Tyrus 1.0, Jersey 2.0, Mojarra 2.2.0 and Weld 2.0.0.SP1 but since that time, those implementations have evolved quite a lot. As of today, the current release of Tyrus is 1.4, the current release of Jersey is 2.5.1, the current release of Weld is 2.0.5 and the current release of release of Mojarra is 2.2.5.

So what to do if you want to use one of the new features provided by one of those implementations in GlassFish 4? One way is to wait that the specific version of that implementation, say Jersey for example, is integrated in a nightly build of the GF 4.0.1 branch. Another solution is to upgrade the specific implementation (e.g. Jersey) in an existing GlassFish 4 setup. The following posts explains how to update Tyrus, how to update Jersey, how to update Weld and how to update Mojarra in a GF4 setup. 

It should be mentioned that no extra testing has been done, so clearly do not do this in any critical environments. And if the updated setup is not stable, it is always easy to come back to the initial configuration. Most of the time, it's just a matter of putting back the original implementation Jar and restarting GlassFish. For Jersey, the provided update script is able to restore the initial configuration if needed. 
Also, since Jersey has dependencies on HK2 and since HK2 has been updated between GF 4.0 and the 4.0.1 branch, it is only possible to update Jersey in a GlassFish 4.0.1 build.

In any cases, if you are using GF 4 with an updated version of Tyrus, Jersey, Mojarra or Weld, we would like to hear your feedback!

Friday Dec 20, 2013

Server Sent Events (SSE) in Glassfish/Jersey

As you know, HTTP is a stateless protocol. For most use cases in the enterprise, the statelessness of HTTP is a huge boon for scalability - a benefit that is also extended to REST. However, there is a certain class of arguably emerging use cases for which the stateless nature of HTTP is actually a scalability challenge. These use cases require the bidirectional, full-duplex, asynchronous characteristics of stateful protocols such as TCP. Examples include chat-like online collaboration, stock-ticker like command-control/monitoring, online gaming and the like. WebSocket (and the Java API for WebSocket newly included in Java EE 7 :-)) is ideal for these cases. Between the seemingly diametric opposites of plain HTTP and WebSocket, there's also Server Sent Events (SSE). SSE is aimed at yet another scenario - a steam of events generated by the server and consumed passively by the client. Although not standardized in JAX-RS 2/Java EE 7, Jersey/GlassFish includes support for SSE.

In an very detailed blog post, Rahman Usta of the Istanbul JUG explains SSE and demonstrates a non-trivial use of the Jersey/GlassFish support for SSE.

Thursday Nov 21, 2013

Jersey 2.x Tracing support

"Rest is the sweet sauce of labor." (Plutarch – a long time ago!)

Jersey is JAX-RS 2.0 Reference Implementation and as such it's fully compliant to JSR 339. The Jersey Team goes beyond the specification by adding features and functionalities to their JAX-RS implementation. Overtime, some of those features might be good candidates for standardization.  The Client API is a good example of that. In JAX-RS 1.x, Jersey and some other implementations has their own proprietary Client API. In JAX-RS 2.0, the Client API has been standardized and is now part of the specification. So it is not uncommon to have, in an implementation, features that are (not yet?) part of the specification. Those extra capabilities are also a way for an implementation to differentiate itself from the other implementations.

Tracing is a feature that was available in Jersey 1.x, this feature has now been ported to Jersey 2.x (2.3 and above). The Jersey Tracing capabilities allows to easily diagnose server-side request processing pipelines.  Libor Kramoliš, a member of the Jersey Team, has written a detailed post on how to use the Jersey's Tracing capability.

Friday Jul 06, 2012

Jersey 2 Integrated in GlassFish 4

JAX-RS 2.0 has released Early Draft 3 and Jersey 2 (the implementation of JAX-RS 2.0) released Milestone 5.

Jakub reported that this milestone is now integrated in GlassFish 4 builds. The first integration has basic functionality working and leaves EJB, CDI, and Validation for the coming months.

Jersey 2.0 in GlassFish 4

TOTD #182 explains how to get started with creating a simple Maven-based application, deploying on GlassFish 4, and using the newly introduced Client API to test the REST endpoint.

GlassFish 4 contains Jersey 2 as the JAX-RS implementation. If you want to use Jersey 1.1 functionality, then Martin's blog provide more details on that. All JAX-RS 1.x functionality will be supported using standard APIs anyway. This workaround is only required if Jersey 1.x functionality needs to be accessed.

Here are some pointers to follow

Provide feedback on Jersey 2 to users@jersey.java.net and JAX-RS specification to users@jax-rs-spec.java.net.

Wednesday Mar 28, 2012

Jersey 2.0 Milestone 2 Now Available

Jersey 2.0 milestone 2 is now available. It builds upon the first milestone and adds several new features such as server-side asynchronous processing, server-side content negotiation, improved JAX-RS parameter injection, and several others.

ALT_DESCR

The REST endpoints can be published on Java SE HTTP Server, Grizzly 2 HTTP container, and some basic Servlet-based deployments. It also provides HTTPURLConnection-based client API implementation. Read about these and more about what's new in Marek's detailed post. Of course this is also the future reference implementation for JAX-RS 2.0.

Feel like trying it out? Simply go to Maven Central (of course none of this is production quality at this point). The latest JAX-RS Javadocs and Jersey 2.0 API docs are good starting points to explore. And provide them feedback at users@jersey.java.net.

Sunday Mar 18, 2012

RESTful Java on Steroids (Parleys, Podcast, ...)

As reported previously here, the JAX-RS 2.0 (JSR 339) expert group is making good progress.

If you're interested in what the future holds for RESTful Java web services, you can now watch Marek's Devoxx presentation or listen to him in the latest Java Spotlight Podcast (#74).

ALT_DESCR

Marek discusses the new client API, filters/handlers, BeanValidation integration, Hypermedia support (HATEOAS), server-side async processing and more.

With JSR 339's Early Draft Review 2 currently out, another draft review is planned for April, the public review should be available in June while the final draft is currently scheduled for the end of the summer. In short, expect completion sometime before the end of 2012.