Posts Tagged ‘rest’

Adding Jersey to a GAE Maven Project

September 3, 2013

Continuing from my post yesterday, Getting Maven, GAE, and Eclipse Working Together, I’m adding Jersey to my test GAE project to finish proving the Maven integration and test that I can get my favorite REST library up and running both locally and as a full fledged GAE project.

Adding Jersey

Jersey is one of the few “magical” (read: annotation) libraries I use.  I really don’t like magic in my code.  It is great when it works, and miserable when it fails… and it always fails at inopportune moments…

We start by adding a new dependency to the pom file:

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <!-- if your container implements Servlet API older than 3.0, use "jersey-container-servlet-core" -->
    <artifactId>jersey-container-servlet-core</artifactId>
    <version>2.2</version>
</dependency>

The artifactId started out as “jersey-container-servlet” but since GAE only supports the Servlet 2.5 spec we follow the comment and append “-core”.

Next, we quickly write a test Jersey class:

package mavengaetestproject.mavengaetestproject;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/jerseyws")
public class TestJerseyWS {

    @GET
    @Path("/test")
    public String testMethod() {
        return "this is a test";
    }
}

And then update the web.xml:

<servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
    <init-param>
        <param-name>jersey.config.server.provider.packages</param-name>
        <param-value>mavengaetestproject.mavengaetestproject</param-value>
    </init-param>
    <init-param>
        <!-- speed up initial Jersey loading by deactivating WADL -->
        <param-name>jersey.config.server.wadl.disableWadl</param-name>
        <param-value>true</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Jersey Web Application</servlet-name>
    <url-pattern>/context/*</url-pattern>
</servlet-mapping>

Finally, run the appengine:devserver maven target, and once the server is up and running open a browser to http://localhost:8080/context/jerseyws/test ; You should see the “this is a test” message.

And there we have it: Maven, Eclipse, GAE and Jersey all working nicely together.

Deploying to the GAE

That’s all well and good, but I want this thing actually in the cloud, not on a dev server.  It may seem obvious, but I failed to do this first: you need to create your project in your GAE account.  You might need to update the application tag in the webapp/WEB-INF/appengine-web.xml to match the GAE application identifier.

At this point you should be able to run the Maven appengine:update target.  If working from inside Eclipse, it is probably easier to log into Google beforehand, AND you WILL need to configure the Eclipse Run As configuration for UpdateApplication to use the external Maven environment (see the other post if you need a refresher on why).  If running Maven from a command line, it will pop open your default web browser, prompt you to log in, and then provide a code to put back into your console/shell to allow it to continue.  For me, it worked cleanly from both environments (once I had the Maven config corrected in Eclipse) and my REST servlet was up and running easily.

At this point I’ve completed everything I intended to accomplish.  It took a little longer than planned and with the mish-mash of tech that didn’t always line up correctly I hope this helps others out.

Advertisements