NetBeans: Jersey and Tomcat

In my blog entry Project Jersey and Java-Based REST, I used several screen snapshots and some text to illustrate how NetBeans 6.1 can be used with Jersey (the JSR-311/JAX-RS reference implementation) to quickly and easily develop RESTful web services from database tables. The process illustrated there takes advantage of the ability of NetBeans 6.1 (which many other IDEs now have as well) to generate JPA-compliant entity classes from source database tables. Similarly, the ability of NetBeans to automatically generate Jersey artifacts for JPA entities was also used and illustrated.

In the referenced blog entry, I did not talk much about the differences of deployment to Tomcat or to GlassFish or other web server. While much of the process is the same regardless of the server used, the JPA persistence.xml file does need to be altered. In this blog entry, I'll focus on the deploying the JPA-backed Jersey-based RESTful web services on Tomcat.

The default persistence.xml file generated as part of the JPA entity generation process (and based on my wizard settings) is shown next:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="SimpleJerseyProjectPU" transaction-type="JTA">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <jta-data-source>jdbc/hr</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties/>
  </persistence-unit>
</persistence>

The NetBeans-centric article Getting Started with RESTful Web Services on Tomcat points out in the Configuring the Persistence File section how to change that file for Tomcat. In particular, it recommends changing that file to remove the jta-data-source element, to change the transaction-type attribute of the persistence-unit element to RESOURCE_LOCAL, and to specify JPA implementation-specific provider properties in the file. For my Oracle database using TopLink Essentials, the persistence.xml file now looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="SimpleJerseyProjectPU" transaction-type="RESOURCE_LOCAL">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <!-- <jta-data-source>jdbc/hr</jta-data-source> -->
    <exclude-unlisted-classes>false</exclude-unlisted-classes>

    <properties>
      <property name="toplink.jdbc.user" value="hr"/>
      <property name="toplink.jdbc.password" value="hr"/>
      <property name="toplink.jdbc.url" value="jdbc:oracle:thin:@localhost:1521:ORCL"/>
      <property name="toplink.jdbc.driver" value="oracle.jdbc.OracleDriver"/>
    </properties>

  </persistence-unit>
</persistence>

The previously referenced article also pointed out some other useful changes that I needed to make. For example, I copied the libraries specified (except for Derby because I was using Oracle) in the Copying Libraries to Tomcat section to the appropriate Tomcat directories as specified.

During the NetBeans generation process, the web.xml (WEB-INF) file and the context.xml (META-INF) file are generally taken care of automatically.

With the change to the persistence.xml file and the appropriate libraries copied to the appropriate Tomcat directories, it was easy to use NetBeans' "Test RESTful Web Services" feature to have the newly generated web services automatically deployed (to Tomcat in this case because it was my currently selected server) and have a browser-based client access the deployed web services.

---

In somewhat related news, I found two recently posted blog entries on REST to be particularly interesting. In REST vs REST, Anthony Goubard differentiates between what he calls "Pure REST" (close attention to HTTP operations GET, POST, PUT, DELETE and the JSR 311 approach) and the "RESTful Way" (more traditional HTTP servlet approach with use of GET and/or POST and URL parameters). Anthony then goes on to delineate problems he sees with the "Pure REST" approach.

The second article is REST Anti-Patterns by Stefan Tilkov. The first two of his eight REST anti-patterns are: 1) Tunneling everything through GET and 2) Tunneling everything through POST. (By the way, Stefan's short entry WS-Dilemma is poignant and worth the brief read.)

What these two interesting and useful blog entries demonstrate is that while many people are choosing REST for their web services approach, there is still much disagreement about what qualifies as REST at all, let alone as an efficient REST approach. Although such differences can be distracting at times, I generally prefer this type of discussion and bantering of ideas because I believe it leads to a Darwinian effect (thanks, Bill, for pointing out the application of this term to software development) in the software industry.