Skip to main content

RESTful Services using Jersey 2.0

Jersey is an implementation of JAX-RS specification which provide API's for developing and exposing applications designed following principles of REST architectural style.

Jersey is now part of glassfish that means the upgrade 2.0 is provided from glassfish and has lot of changes shipped with it compared to Jersey 1.0. Here's the migration guide.

Though above migration guide will help. My development involves using Oracle JDeveloper so I haven't really got a chance to use the migration steps myself so I'm making some hand written code again to get a feel of Jersey 2.0 and also along the way I'll try to document needed changes for anyone else going my path.

This document includes code that can be used by Java and Oracle ADF developers. Let's roll into code now:

Maven dependencies for the maven people:

pom.xml:

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.rdev.jersey</groupId>
    <artifactId>Jersey2Demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>war</packaging>
    <repositories>
        <repository>
            <id>maven2-repository.java.net</id>
            <name>Java.net Repository for Maven</name>
            <url>http://download.java.net/maven/2/</url>
            <layout>default</layout>
        </repository>
    </repositories>
    <properties>
        <jersey2.version>2.19</jersey2.version>
        <jaxrs.version>2.0.1</jaxrs.version>
    </properties>
    <dependencies>
        <!-- JAX-RS -->
        <dependency>
            <groupId>javax.ws.rs</groupId>
            <artifactId>javax.ws.rs-api</artifactId>
            <version>${jaxrs.version}</version>
        </dependency>
        <!-- Jersey 2.19 -->
        <dependency>
            <groupId>org.glassfish.jersey.containers</groupId>
            <artifactId>jersey-container-servlet</artifactId>
            <version>${jersey2.version}</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-server</artifactId>
            <version>${jersey2.version}</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-client</artifactId>
            <version>${jersey2.version}</version>
        </dependency>
    </dependencies>
    <build>
        <finalName>Jersey2Demo</finalName>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

JDeveloper 12.2.1.3: (***** JDeveloper/ADF Developers only****)


web.xml:

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
  
<web-app>
  
  <display-name>Archetype Created Web Application</display-name>
    
  <servlet>
        <servlet-name>jersey-serlvet</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
        <init-param>
             <param-name>jersey.config.server.provider.packages</param-name>
             <param-value>com.rdev.jersey</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
   
    <servlet-mapping>
        <servlet-name>jersey-serlvet</servlet-name>
        <url-pattern>/rest/*</url-pattern>
    </servlet-mapping>
      
</web-app>

Notice the package changes from com.sun.jersey.* to org.glassfish.jersey.*

Now let's write the resource class:

HelloResource.java:

package com.rdev.jersey;

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

@Path("/hello")
public class HelloResource{
     @GET
     public String getHelloWorld(){
         return "Hello World from Jersey 2!";
     }
}



So steps needed for migration for simple resources as above would be:

  1. change the dependencies in pom.xml.
  2. ServletContainer changes in web.xml.
  3. package import changes if any.

Happy Coding ✌






Comments

Popular posts from this blog

Spring Boot - RestTemplate PATCH request fix

  In Spring Boot, you make a simple http request as below: 1. Define RestTemplate bean @Bean public RestTemplate restTemplate () { return new RestTemplate (); } 2. Autowire RestTemplate wherever you need to make Http calls @Autowire private RestTemplate restTemplate ; 3. Use auto-wired RestTemplate to make the Http call restTemplate . exchange ( "http://localhost:8080/users" , HttpMethod . POST , httpEntity , String . class ); Above setup works fine for all Http calls except PATCH. The following exception occurs if you try to make a PATCH request as above Exception: I / O error on PATCH request for \ "http://localhost:8080/users\" : Invalid HTTP method: PATCH ; nested exception is java . net . ProtocolException : Invalid HTTP method: PATCH Cause: Above exception happens because of the HttpURLConnection used by default in Spring Boot RestTemplate which is provided by the standard JDK HTTP library. More on this at this  bug Fix: This can b...

Settings.xml for Maven, JFrog

For development and deployment of applications we always use an artifactory in real-time world to host artifacts needed for your build and also as a target to deploy artifacts generated in the build process. For Maven, to communicate with artifactory we need a settings.xml file which is usually located at "/User/rake/.m2/settings.xml" this file consists of how to authenticate to the artifactory servers and authorizations to read/ write to different locations like release, snapshots e.t.c... Settings.xml can be generated using the artifactory you're using which in my case is JFrog , but here's a sample settings file for your reference incase you're feeling lazy☺ <?xml version="1.0" encoding="UTF-8"?> <settings xsi:schemaLocation= "http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns= "http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi= "http://www.w3.org/2001/XM...

Stored Procedures in ADF

One of the common requirements for ADF programmers is to invoke Stored Procedures and Functions. Implementing this is so simple with few lines of code in Java classes used under business components. Following code snippets from fusion guide  will help execute different procedures with and without arguments. Execute stored procedure with No Arguments: public void callProcWithNoArgs() { getDBTransaction().executeCommand( "begin devguidepkg.proc_with_no_args; end;"); } Execute stored procedure with only IN arguments: Procedures often take arguments in order to process some business logic. Arguments are limited from none to many. In order to use stored procedures with argument mode we need to use JDBC PreparedStatement object. How To: Create connection Create a JDBC PreparedStatement with procedure details wrapped in a PL/SQL begin..end block. Assign the values to arguments if any. Execute the statement. Close the statement. protected void callStoredPr...