Support for CXF in Enunciate

Enunciate is a popular framework which can be used to deploy and expose Java applications as WEB applications. I had read good reviews about it long before I joined the CXF JAX-RS project.

Thus I was quite excited when I found out from this announcement CXF JAX-RS was also optionally supported. Please see some more information from the modules page which says that CXF JAXWS and JAXRS frontends are supported (as a side note, CXF users can deploy endpoints without depending on Spring by relying on non-Spring CXF servlets).

I would like to use this post to encourage the leads of other higher-level frameworks to let users choose between different web services enablers and those exposing Java applications as RESTful services in particular, by doing it the way Enunciate did.

It will not harm. Giving users a choice never harms. The most likely sideeffect is that your favourite framework will likely see more users coming in.

I hope Enunciate will make CXF and CXF JAX-RS more visible. Likewise I hope Enunciate will enjoy seeing a number of its users rising in turn too. I will be happy to play with this framework later on too and see if I can contribute somehow.

Enjoy !

The RESTful Java with JAX-RS book

Bill Burke, the author of RestEasy, has had his new book, RESTful Java with JAX-RS, published recently.

Bill is one of the main contributors to the success of JAX-RS so this good JAX-RS reference book with practical examples will be welcomed by all JAX-RS users and ReastEasy fans in particular.

Here I would like to thank Bill for letting us do a small contribution to the book. He kindly approached us and proposed to do a brief description of the Apache CXF implementation of JAX-RS which is what we did. Seeing it being referenced alongside the heavyweights like Jersey and RestEasy is encouraging and humbling.

Finally, Bill, being the true host of the whole project, referenced RestEasy last in the list of the implementations. Very kind. Thanks Bill !

Please give this book a good read :-)

OT: The Fever Pitch

I have to make an admission : I really start liking the way Arsenal FC plays. In fact, I simply can not help waiting to see them playing on the BBC Match of The Day tonight and then reading the reviews in different newspapers and online on BBC and arsenal.com tomorrow, even if they not win. Arshavin is 'to blame'. But now I can also see what a good team Arsenal is.

When I came to work to England nearly 13 years ago, I already was a ManU supporter. A lot of ManU supporters actually live abroad. After living for nearly a year in Manchester I became even more ManU-obsessed, especially after seeing them playing live in Liverpool at Everton, despite the fact I found out that actually there also was a Manchester City FC too, supported by quite a few locals I spoke too :-). I still love watching ManU playing, they are playing for people who watch them and they probably still have the more local-grown talent on the pitch than other teams in the top 4.

That said, Arsenal is the team which I am really excited about at the moment. It was a 'ruined' weekend when they lost to Chelsea but the last weekend was great ! Two weeks ago I watched them playing Stoke on the Match of The Day on Saturday on both RTE1 and BBC and then again the next day on the Match of The Day 2 on BBC.

What is the story ? Another milder version of the Fever Pitch ? And what a great book that was, my friend who is an Everton fan, presented it to me the other day.

I realized this Monday Arshavin inspires me. He is a match winner and a real fighter. Arsenal are a bit "vertically challenged" upfront as one of Arsenal fans said the other day :-), but they are a great team to watch.


Go Arsenal !

The argument about fast JSON processors

I have heard by now a number of times that Jettison is slower than Jackson when it comes to handling large JSON sequences.

To be honest, I am not sure what this argument is about. Perhaps because I do not understand JSON ? I would rather see statements like : Jackson is a popular JSON processor which can let users create correct JSON sequences without users having to introduce JAXB dependencies. This is something I can get.

The argument about the performance sounds like a red-herring to me. Are you writing a service which returns a 7OK JSON sequence ? Is it the sign you may need to rethink the way your service has been designed ? IMHO JSON is not the means to pass around huge sequences, it is the format which has been designed to help users streamline the development of client-facing Web frontends, at least this is my understanding.

So if you need to deal with large chunks of data then may be you may want to return a JSON-formatted Atom feed, something that Abdera supports, with links pointing back to the next chunks of data. Or just use XML for a similar purpose ?

And if you write your Ajax JavaScript clients handling JSON sequences of small to medium size then perhaps the performance issue is not actually an issue ?

Having said all this, I will be happy to see Jettison supporting streaming eventually. Hope it will happen soon. The most important thing though is that it will now more likely to produce correct JSON sequences which is what users really want.

Better Jettison is on the way

It would be fare to say the Jettison project has been stagnating for a while now.

I do think it has been doing really well as part of CXF, by generating and consuming JSON sequences from and into JAXB beans. It has not been always 'successful' but still worked well for many cases. In addition, CXF JAX-RS provides a number of options for customizing input and output JSON sequences on top of Jettison :

http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-JSONsupport
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-CustomizingJAXBXMLandJSONinputandoutput

That said, Jettison has not been capable of handling recursive structures well, and may 'surprise' now and then in a number of other cases. Some CXF users have tried a well-rated Jackson, however, some users are still like working with the default Jettison-based CXF JAX-RS provider.

Thus it was just a matter of time before motivated and interested users were to step in and contribute to Jettison. John Worrell has recently done a major refactoring of the Jettison XMLStreamWriter implementation and his patch has already been applied by Dejan. In fact, CXF trunk has just been updated to depend on Jettison 1.2-SNAPSHOT containing the improved writer . This is a great contribution from John and I do hope it will give a new lease of life to Jettison.

If you do use Jettison, with or without CXF, then please give the latest SNAPSHOT a try. Please report the issues if any to the Jettison users list or leave a comment at Jettison-87 and also close the JIRAs which may have been fixed, example, a well-known Jettison-57 has been fixed along the way after the patch from John has been applied.

So it is a good news for Jettison users. Another CXF user has actually expressed an interest in enhancing Jettison for it to support streaming.

The better Jettison is on the way.

Embracing Atom with CXF

Until recently, it has been possible to write an AtomPub JAX-RS application in CXF by using Abdera Feed or Entry classes like this :

public class AtomPubResource {

 @GET
 @Path("/feed")
 public Feed getCollection() {
     // create Feed as needed
 }

 @GET
 @Path("/feed/{id}")
 public Entry getEntry(@PathParam("id") int id) {
     // get individual entry
 }

 @POST
 @Path("/feed")
 public void addEntry(Entry entry) {
     // update collection
 }

 // etc
}

Going this route gives users the most control over how a given feed is initialized and how entries have the actual content captured. Some frameworks provide JAXB-based classes for dealing with Atom primitives such as feeds and entries - I am not quite keen on extending CXF JAXRS in a similar way, after all, what it can give a user apart from introducing alternative foreign classes into their main application code ?

With the addition of AtomPojoProvider provider and Atom-specific extensions few more options are now available for CXF users to start playing with Atom (note the provider and extensions code may still get changed).

To start with, users can now simply do :

@Path("/store")
public class BookStore {

 private Books books = new Books();

 @GET
 @Path("/books")
 @Produces(
  {
   "application/xml",
   "application/json",
   "application/atom+xml;type=feed"
  })
 public Books getBooks() {
     return books;
 }

 @GET
 @Path("/books/{id}")
 @Produces(
  {
   "application/xml",
   "application/json",
   "application/atom+xml;type=entry"
  })
 public Book getBook(@PathParam("id") int id) {
     return books.getBook(id);
 }

 @POST
 @Consumes(
  {
   "application/xml",
   "application/json",
   "application/atom+xml;type=entry"
  })
 public void addBook(Book book) {
     books.addBook(book);
 }

 // etc
}

What happens here is that you continue write your Java JAX-RS code, the way you may often do, without introducing any direct dependencies on the Atom-specific classes, and just experimenting at the same time with implementing an AtomPub application on top of your collection classes like Books. Starting with AtomPub and Atom is now as simple as updating Produces and Consumes values and registering an AtomPojoProvider.
As long as your Books class has default collection setter and getter methods, getBooks and setBooks returning and accepting a List of Book instances in this case, and happy with some of default Feed and Entry properties, that is all that needs to be done.

The next step is to tell the AtomPojoProvider the names of the collection getters and setters on individual classes such as Books.

The next step is to register Feed and/or Entry builders which can help AtomPojoProvider with setting various Feed and Entry properties, still without introducing direct dependencies in your main code.

Finally, you can take the complete control with registering Feed or Entry writers or readers. This option is similar to having Abdera Feed or Entry classes in your main application code except that these providers will let you deal with these classes outside of the main application code.

CXF users will now have plenty of options for writing AtomPub applications on top of the JAX-RS runtime. Give it a try and enjoy !