I went to MuleCon 2008 and got to meet not only a lot of cool Mule engineers and users, but also Dan Diephouse, the original author of CXF. The Mule people have a really active and energetic community and are now supported by a company called MuleSource, which employs many of the Mule engineers. Among the many topics that came up, one that I took interest in was REST. I asked Dan about the REST support in CXF, which I didn’t know a lot about when I asked. He said that they had an HTTP binding, but recommended going toward JAX-RS.

Coincidentally, one of our customers actually asked the next day about using the HTTP binding with CXF! So I had a look at it and it’s basically right on. It’s annotation based and uses Codehaus’ Java REST annotations (JRA). It’s a small set of method annotations first consisting of GET, PUT, POST, and DELETE to specify which HTTP method will get you to this Java method. Next, there’s a way to map the path and headers to method arguments. That’s it. And that’s pretty much all you need.

Now, I’ve looked at JAX-RS and while I’ll admit that conceptually it’s closer to the original intention of REST, I think it makes things way too complicated. Most of the people using REST do not truly understand the notion of resources and verbs and all that good stuff. They just see the power of passing different parts of a URL to a certain method. When it comes down to the implementation of most normal REST schemes, you end up with a mapping from a URL to a method invocation. That’s what the JRA does in a very simple way.

JAX-RS defines an object tree based on the resources and sub-resources specified by a path. Methods may return sub-resources on which further resource specification is invoked until you get to a terminal method. Did you get that? It’s very nice, academically. However unless you’ve been working with REST for a while and are really a dyed-in-the-wool believer, all that just gets in the way when you’re just trying to map a URL to code. I question the ability to make this fast as well, given the sub-resource concept. Not to mention that the spec itself says it does nothing to create client. I’m a believer that there should be a service interface shared on both the client and server: the server should implement it and the client should get a proxy facade using it. JRA lets you do that and JAX-RS doesn’t.

Anyway, this is probably a futile discussion as JAX-RS is being discussed for inclusion in the next JavaEE standard (!) and a lot of people are thus looking at it as the way to do REST on Java. I hope I’m wrong…

Ok, ok… so it’s been a while since I had a chance to blog, but I have two good excuses. The week before last, I was at AjaxWorld, giving a presentation and meeting a bunch of interesting people. The conference was very fruitful, but they didn’t have wireless! :-/ Anyway, thanks to everyone who came out to my presentation (all 10 of you ;-)), even though it was 5:20pm after a day that started with 7:00am keynote.

Last week, I was sick and a bit dazed, so I figured it was a good time not to blog a fever-inspired rant.

This week, I’ll be at the MuleCon in San Francisco, checking out the cool things that people are doing with Mule. One of the fun things we did was to integrate Resin IoC with Mule so you can pull down objects configured in Resin IoC natively in your Mule configuration. If you’re going to be at MuleCon, let me know and we can meet up.

Next Monday is our Quercus tutorial at the Java Meetup group in San Francisco. The guest list is full! I’m excited, but if for some reason you can’t make it or didn’t sign up in time, I’ll be posting the presentation here afterwards.

Anyway, today I bring you a nice little gem from Scott on the Resin-Interest mailing list (you are signed up for it, aren’t you?). Someone asked how to prepare their Resin installation for “prime time” and Scott offered up these very cool suggestions:

• The default <dependency-check-interval> should be raised to a minimum of 60s or even larger.
• If you haven’t already profiled your application, remember that Resin’s /resin-admin has a profile tab. It’s surprisingly
  lightweight, so it’s possible to use even on a production machine. It’s always a good idea to be aware of where your application is
  spending its time.
• Take a few thread dumps using the /resin-admin, so you get an idea of the baseline behavior. If something does go wrong, you’ll want to be able to distinguish the normal behavior from the unusual. It’ll also get you in the habit of taking thread dumps, for a freeze or CPU spike.
• On Linux (and other Unix), check your file descriptor max with uname -a. The defaults are surprisingly low.
• Remember that threads need virtual memory, too. That’s an issue for 32-bit systems. 1024 threads x 1m stack size = 1G memory.
• Become familiar with the jconsole view (or some other jmx admin).

If you do these and have a support question, we’ll be in a much better position to help you out. In fact, these steps will be helpful in getting to know your system even better. If anyone else has suggestions on how to prepare a system for prime time, please comment!