This is the thrid release of JBoss’s JSR-311, JAX-RS, Restful Web Services implementation. Nothing special in this release, just a lot of bug fixes the community found as well as more spec-feature complete. We have some more things coming down the pipe in the next month, so stay tuned!

Links to where to download, post user questions, and our documentation are all available on our WIKI.

Release Notes - Resteasy - Version Beta3

Bug

• [RESTEASY-25] - mime property types ignored when matching resource methods to requests
• [RESTEASY-26] - MessageBodyWriter matching should use the entity class, not the method’s reflected return type.
• [RESTEASY-27] - Resource Locators should be dynamically processed

Task

• [RESTEASY-6] - Implement all methods with decode parameter within UriInfo
• [RESTEASY-20] - Suport for @Path.limited

I finally got around to creating a new release for the next rev of our JAX-RS, Java RESTful Web Services, implementation. This release targets the 0.7 release of the JAX-RS specification. There’s a still a few features I haven’t implemented yet, but hope to get them out soon as the spec starts to solidify. Especially new in this release is a new embeddable container so you can run things within junit tests, or just serve up a small restful web service from your classpath. We’ve been using this embeddable container to unit test our implementation and finally made it available to the masses.

Check out our project page or download the new release.

Release Notes - Resteasy - Version Beta2

Bug

• [RESTEASY-1] - DefaultPlainText.MessageBodyWriter should not write anything (arrays especially)
• [RESTEASY-2] - If Response has set Content-Type, then that content type should be used
• [RESTEASY-9] - Subresources erroneously considered as root resources
• [RESTEASY-17] - Spec mandates supporting MultivaluedMap for form-urlencoded media types
• [RESTEASY-18] - @QueryParam should not return x-www-form-urlencoded parameters
• [RESTEASY-24] - WebApplicationException and http status codes

Feature Request

• [RESTEASY-11] - Standalone server

Task

• [RESTEASY-4] - Implement variants
• [RESTEASY-13] - Support @Context field injection
• [RESTEASY-14] - Support @Context injeciton of HttpServletRequest/Response
• [RESTEASY-16] - Support injection of javax.ws.rs.core.SecurityContext
• [RESTEASY-19] - Support for StreamingOutput
• [RESTEASY-23] - Integration test for SecurityContext

It’s amazing to me the attention and outrage expressed against Bill Belichick and the Patriots for Spygate when there’s much more serious cheating going on in the NFL.  I mean, Belichick gets lynched for taping a team to figure out its tendencies.  A practice that I sincerely believe Belichick thought was a grey area in the rules.  Anyways, that’s what coaches are paid to do, analyze film to gauge a team’s tendencies.

In comparison, we have a multitude of other teams tampering with free agency.  For example, the 49er’s were recently penalized a 5th round draft pick for tampering with the Bear’s Lance Briggs in free agency.  The quality of players (or lack thereof) has a much more dramatic affect on the outcome of a game than whether or not a coach can crack an opposing team’s defensive signals.  How about the Patriot’s 2006 season?  Remember the Dion Branch fiasco when the Patriots were basically forced to trade their best receiver away at the beginning of the season?  Where was the outrage, outside of New England, when the Jets tampered with Dion Branch?  The 2006 AFC championship game against the Colts was so close one play could have changed the outcome of the game.  Ya think having Branch would have made a difference?  No, not at all  ;).

It doesn’t stop with free agency tampering.  Numerous teams have also violated the salary cap.  Those same 49ers were penalized $400000 for violating the cap in Steve Young and Brent Jone’s contracts.  The same Steve Young who lambasted Belichick and the Patriots on ESPN.  Its not just the 49ers.  The Broncos were penalized, not once, but twice for salary cap violations.  The first was in regards to John Elway’s contract.  Should the Broncos also have an asterix next to their superbowl victories?  Where was the outrage?   Spectre, where are you?  Oh, I forgot, you’re a senator from Pennsylvania, not one from Georgia or Wisconsin.

All and all, I’m fine with the Patriots getting punished by the commissioner.  What I’m not fine with is the Patriots being treated as a special case by the media and the fans.  I want to see equal outrage against other teams that violate the rules, equal press coverage.  Its only fair that fans in San Francisco, New York, and Denver experience similar humiliation and witch hunts.

A great article by Stefan Tilkov on Addressing doubts on REST.  This and his previous article are a must read for any REST noob.  I wish I had them available when I was researching REST almost a year ago.

I recently ran into the situation where I wanted to do lazy, on-demand, initialization of a registry. In previous applications, I would just use get()/put() from java.util.ConcurrentHashMap because I didn’t care if something was created more than once accidentally as it would eventually, and quickly, sort itself out and all I’d lose is a tiny garbage collection. Unfortunately, in my current project, a registry entry cannot be allocated twice as two different versions of it might be used concurrently and each registry entry holds and maintains state. These resources need to be individually unique. Thankfully, java.util.ConcurrentHashMap has a nice method called putIfAbsent(). This method does the atomic equivalent of:

if (!map.containsKey(key)) {
   return map.put(key, value);
} else {
   return map.get(key);
}

So, what I can do is do a mini double check. When I lookup at entry, if it doesn’t exist, allocate a temporty version of it and call putIfAbsent.

public V get(K key) {
   V value = concurrentMap.get(key);
   if (value != null) return value;

   value = new Value(...);
   V tmp = concurrentMap.putIfAbsent(value);
   if (tmp == null) {
      return value;
   } else {
      value.cleanup();
      return tmp;
   }
}

If putIfAbsent returns null, then I know nobody has created a version concurrently.  If it doesn’t return null, then I know somebody has initialized this entry concurrently.  In that case, I cleanup the created value, and return the one already in the registry.  This looks a lot like the double-check-nono, but it actually isn’t as ConcurrentHashMap performs the putIfAbsent atomically.

I’ve been playing around a little bit with the idea of creating a RESTFul MOM/ESB where the client requests a specific format and the server transforms the content if it can. For an ESB, this usecase would normally turn up for various XML-based messages and documents. The client would request an XML document of a certain schema and the ESB would return that format, performing a transformation if applicable.

For a RESTFul ESB, I’d want to use HTTP content negotiation. The problem is, AFAIK, there is no standard MIME type, other than “application/xml”, that allows you to specify an XML format with schema information. Being a REST noob, I emailed my friend Steve, a REST enthusiast, and asked him if it would be ok to embed schema information into the media type. My first thought was the media type would be:

application/myschema+xml

Steve’s response was you can’t just make up a MIME type on your own and expect it to work well on the Internet without registering it. At first I thought, what’s the big freakin deal? But then I realized, what if you want to point your browser to a message in a remote RESTFul queue and just view its content? If you use “application/myschema+xml” your browser ain’t gonna understand it.

So, I decided to do a search on “decentralized mime types” and came across a few blogs from Stefan Tilkov, Dan Diephouse, and James Strachan. Here’s a summary (sorry if I left out anything)

Use AtomPub

One idea was to use AtomPub . I don’t like this idea at all. One, I just want to send a bloody XML document! KISS baby KISS! Second, if I’m going to use an envelope format, why not just use SOAP and WS-*? (no thanks). This, IMO, sort of defeats one of the general principles of REST.

Define a new decentralized MIME type

The idea would be to define a decentralized MIME type like this:

application/data-format;uri=http://mediatypes.example.com/foo/bar

The uri would point to something like an RDDL document that defined the real format. Beyond KISS, what I don’t like about this approach is that again, I have no way of pointing my browser (or some other generic client) at the resource and just viewing it.

Use MIME properties

I saved the best for last. The final idea was to embed format information within MIME properties:

application/xml; schema="http:/..."

application/octet-stream; data-format=java

Use a registered MIME type, but append extra format information as a MIME property. I did a test on this with Firefox and Safari and it doesn’t screw up the viewing. So for me, MIME properties it is! I would be interested in links to other thoughts on this.

I’m pleased to announce the first beta release of the JBoss Resteasy JAX-RS implementation!

After about 4 months of on and off development, I finally have a working version of the new JSR-311, JAX-RS specification. For those of you who don’t know, JSR-311 is a RESTFul Web Services implementation for Java and is slated to be included within Java EE 6. The spec is still a bit of a moving target, but its still pretty useful. Let me know what you think!

Features:

• JAX-RS implementation (almost full, still have a few minor things here and there)
• Portable to any app-server/Tomcat that runs on JDK 5 or higher
• EJB 3.0 and Spring integration
• Client framework to make writing HTTP clients easy (JAX-RS only define server bindings)

Where can I find out more?

All information, including where to download it, is available on our Resteasy WIKI.

Maven would be cool if the plugins weren’t so god awful!  I mean, are these plugin developers idiots?  Do they even use their crap?  I just spent a good day trying to get the maven-ear-plugin to work only to give up and do an assembly, only to run into different problems there.  Beyond being totally unintuitive, these specific plugins have horrible horrible documentation.  Add to this fact that the assembly plugin doesn’t even check its syntax.  For example, I had <fileset> and didn’t know why the stupid plugin wasn’t creating the fileset in the jar.  Well, its because I didn’t capitalize the ‘S’  <fileSet>.  Of course no error message.  I had to ditch maven-ear-plugin because it didn’t correctly put transitive dependencies in the directory I wanted automatically.

I just can’t believe people haven’t cleaned up this shit.  Are people really using Maven?   I WANT to like Maven, I WANT to use Maven.  Its too bad its so freakin painful.

I have a confession.  I didn’t really test the code that allowed you to scan /WEB-INF/classes for my Scannotation project.  In the old code, if you run within Tomcat, you’ll get a “jndi:” protocol based URL that my code doesn’t understand yet how to scan

Instead, I obtain the URL by doing a ServletContext.getRealPath(”/WEB-INF/classes”).  Unfortunately, this is not guaranteed to work by the specification, so, if you run into this problem, you’re gonna have to find another way to scan this directory portably.

I’ve released a version 1.02 of Scannotation that has this RealPath fix along with a few other minor bug fixes I found while using the library.

Recently, I had the need to do some JBoss integration testing in a Maven environment. I had to piece together how to do this and couldn’t find one reference point that just gave me all the maven XML I had to cut/paste. So, I thought I’d log it here for others to reference. First of all, in your src/test/resources directory you need a jndi.properties file:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=jnp://localhost:1099

This isn’t used by any of the maven plugins i’m going to show you, but you will need it in your test code if you want to connect at all with JBoss. Next, here’s the build fragment of what you need in your pom.xml

   <build>
      <finalName>jsr311-war</finalName>
      <plugins>
         <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jboss-maven-plugin</artifactId>
            <configuration>
               <jbossHome>/Users/billburke/jboss/jboss-4.2.2.GA</jbossHome>
            </configuration>
            <executions>
               <execution>
                  <id>jboss-deploy</id>
                  <phase>pre-integration-test</phase>
                  <goals>
                     <goal>deploy</goal>
                  </goals>
                  <configuration>
                     <fileName>${basedir}/target/jsr311-war.war</fileName>
                  </configuration>
               </execution>
               <execution>
                  <id>jboss-undeploy</id>
                  <phase>post-integration-test</phase>
                  <goals>
                     <goal>undeploy</goal>
                  </goals>
                  <configuration>
                     <fileName>${basedir}/target/jsr311-war.war</fileName>
                  </configuration>
               </execution>
            </executions>
         </plugin>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
               <skip>true</skip>
            </configuration>
            <executions>
               <execution>
                  <id>surefire-it</id>
                  <phase>integration-test</phase>
                  <goals>
                     <goal>test</goal>
                  </goals>
                  <configuration>
                     <skip>false</skip>
                  </configuration>
               </execution>
            </executions>
         </plugin> ...
      </plugins>
   </build>

First things first, is to use the Mojo JBoss plugin. This allows you to deploy/undeploy to JBoss. You must configure it to point to the JBoss home directory. I have it hardcoded, but you should use an environment variable. There are two executions that are run. One deploys a file I have in my projects target directory, the other undeploys it. These must run in the pre-integration-test phase and post-integration-test phase.

The next blob of XML deals with the Surefire test framework. Surefire will try to run tests before you have packaged and deployed your target archive. This is because in Maven’s lifecycle, testing comes before packaging and Surefire is automatically bound to run tests in the “test” phase. We turn this off and instead tell Surefire to run during the “integration-test” phase after our archive has been packaged and deployed to JBoss.

The mojo plugin also allows you to start and stop jboss. I could not get this to work with JBoss 4.2.2. Since I prefer to run JBoss manually when integration testing anyways, I was too lazy to investigate further.