NetBeans 6.0 Beta 1 REST Support Engineering Plan

This is the beta 1 engineering plan for the RESTful service support in NetBeans 6.0.


Due to a change of plan to add support for StrikeIron services, we did not fully execute on the M10 engineering plan. We only completed the following two features from the M10 requirements:

  • Add support for generating skeleton RESTful service code not tied to an entity class.
  • REST Component Palette.

For beta 1, since we are moving our modules to the update center, we are no longer bound by the feature freeze requirement of M10. Therefore, we are planning to implement some of the M10 requirements along with new requirements during the beta 1 time frame provided that our features are beta quality (no P1 & P2) for the update center.

Here are the high-level requirements for beta 1:

  • Migrate to JSR-311 API.
  • Move to update center.
  • Add support for client creation.
  • Add HTTP monitoring support in test client.
  • Add support for JSON.
  • Improve existing wizard for generating RESTful services from entity classes.
  • Support for Hibernate.
  • Add dialog support for capturing default values when DnD components from the REST palette.
  • Logical view for RESTful Web Services

Due to beta1 slip, we now have three extra weeks to add a few more requirements for beta1:

  • Come up with a set of WADL enhancement requirements for Jersey, e.g. param types, faults, etc.
  • Client-controller container-item pattern
  • Fix Hibernate/ClassCastException issue
  • Minimize the number of bundle jar files from Jersey
  • Support for REST-based components in addition to WSDL-base components in the component palette
  • Create representation model from JAXB classes to facilitate creation of XML instance document
  • Feature polish

Functional Specifications

This section provides high-level functional descriptions of the requirements. For features requiring more detailed specifications, we will add them here as they become available.

Migrate to JSR-311 API

Currently, we are using the pre-JSR API for generating RESTful services. We need to migrate to the current API and the runtime being developed on the Jersey open source project.

Here are the required changes:

  • Replace with explicit creation of with the appropriate status code and response.
  • Replace with
  • Use to create a Response instance including the equivalent of
  • Use annotation instead of javax.annotation.Resource annotation. In addition, use class instead of
  • Remove @SubResource annotation since it is being removed from the API.

Move to Update Center

There are several tasks involved with the UC move.

  • Fill out a request form for publishing modules on the update center.
  • Bundle the jersey libraries with our modules.
  • Work out which modules need to go onto the UC.

Client Creation Support

For each REST resource class, we want to generate a JavaScript client stub that makes it easy for client application to access the RESTful service. At the project level, we will introduce a New action called "JavaScript Client Stubs from RESTful Services". The wizard will allow users to select from a list of projects containing RESTful services and create the client stubs for the services under those projects.

Click RESTful Web Service Client Creation to see detail

HTTP Monitor Support in Test Client

In the JavaOne music demo, we implemented a HTTP monitor for monitoring the HTTP messages. We plan to incorporated this feature into our test client so the code doesn't go to waste.

JSON Support

JSON (JavaScript Object Notation) is a lightweight data-interchange format based on the JavaScript Programming Language. It is a very popular format in the Web 2.0 community, more so than XML. Therefore, we need support it as a mime type for the REST representation.

JAX-WS RI already has an extension for supporting JSON based on Jettison (a JSON StAX Implementation that makes use of JSONObject) in combination with JAXB. It can serialize JAXB-annotated class instances into JSON and back. The same approach can be implemented in the REST runtime. This means that our JAXB-annotated converter classes can be reused without any modification to support JSON. We only need to generate additional HTTP methods with JSON as the mime type. It is up to the REST runtime to marshal the converter instances into the right format.

We also need to enhance our test client to support JSON.

Improve Existing Wizard

The existing wizard for generated RESTful services from entity classes does not allow users to select a subset of the entity classses, nor does it support calculating the closure. We need to improve this. We can reuse some of the existing code in the JPA modules provided that they are migrated to Retouche.

Support Hibernate

This is a request from customer during JavaOne. We simply need to test to make sure our code works against Hibernat.

Dialog for REST Palette Components

We need to display a dialog box for users to enter default values for the parameters to the web service operations during DnD.

Implement Logical View for RESTful Web Services

In order for a class to be a RESTFul resource class, it can either have an @UriTemplate at the class level or at least one @HttpMethod at the method level. In case there is no @UriTempate at the class level, it become fairly difficult for developers to recognize if a class is a RESTful resource. To alleviate this problem, we need to implement a logical view for RESTful web services similar to the logical view for WSDL-based services.

Here is the structure of the logical view:

RESTful Web Services

  - CustomerResource
     - HTTP Methods
        - getXML : CustomerConverter
        - ...
     - Subresource Locators
        - discountCode/ : DiscountCodeResource
        - ....
  - CustomersResource  /customers/
     - HTTP Methods
     - Subresource Locators

Note that the RESTful Web Services node will only appear if there is at least one RESTful resource class in the project.

Enhancement Requirements for WADL

WADL currently has some limitations that we would like to address. For example, it current doesn't include the param types for HTTP methods. This is needed for use to generate better test client and client stubs. It also does not generate fault information. We need to come up with a list of requirements for Jersey to enhance WADL.

Client-Controlled Container-Item Pattern

This is an alternative version of the Container-Item pattern where only one resource class gets generated. Furthermore, PUT can be used to create new items.

Fix Hibernate/ClassCastException

The current generate a persistence service is a plain POJO and not managed by the container. This causes problems with persistence runtime that supports lazy instantiation such as hibernate. It also causes the infamous ClassCastException during redeployment. We need to revisit our persistence service. One possible solution is to generate a persistence service as a servlet instead of a POJO.

Minimize the Number of Bundled Jersey Jar Files

We currently bundle a large number of jar files from Jersey some of which already exist in the appserver. We need to figure out a minimum set of jar files to bundle. Note that we need to work in conjunction with Jersey to minimize this list.

Support for REST-base Components

The StrikeIron components in the component palette are WSDL-based services. We should also provide support for dynamically creating components that are based on REST-based services.

Create Representation Model From JAXB Classes

We need this feature to facilitate creating instance documents from our representation class (converters). This will help make it easier to generate client stubs and eventually help us generate XML instance document from the converters.

Service Manager Integration

The Service Manager currently only lives in the Visual Web Pack. However, this functionality should reside in the base IDE. This will provide a uniform way for the IDE to support partner services for VWP, BPEL and REST. Furthermore, we can leverage the Service Manager to create new components in our component palette by DnD. Therefore, it is highly desirable to move this functionality out of VWP and into the core NB.

Note that we need to get commitment from the VWP team in order to proceed with this project.

Feature Polish

We need to go through all the features we've implemented so far and make sure they are polished. This include improvement the UI, making sure things work in a consistent fashion, etc.

Web Service Manager

Moving Web Wervice Manager to NB core.

QE Plan


Documentation Plan

We also plan to write the following articles for beta1: - Patterns (Container-Item, Client-controlled Container-Item, Standalone) (Nam, 8/24) - Music DB tutorial based on client stubs (Ayub, 8/7) - Converters (Peter, 8/24)


  • REST implementation in Jersey.


*Date* *Task* *Owner* *Comment*
7/16 JSR-311 Migration Peter Liu completed
7/17 Submit UC Request Form Peter Liu completed
7/16 Bundle Jersey libraries Nam Nguyen completed
7/17 Work out UC modules Nam Nguyen completed
7/23 Client Stub Code Generation Ayub Khan completed
7/19 UI for Client Stub Generation Nam Nguyen completed
7/13 HTTP Monitor in Test Client Ayub Khan completed
7/31 JSON Code Generation Support Peter Liu completed
7/31 Logical View Peter Liu completed
7/31 JSON Test Client Support Ayub Khan completed
7/23 Enhance Entity Wizard Nam Nguyen completed
7/27 Dialog for REST components Nam Nguyen completed
8/3 WADL Enhancement Requirements Nam Nguyen on-going
8/6 Client-controlled Container-Item Pattern Nam Nguyen completed
8/17 Hibernate/ClassCastException Nam Nguyen
8/17 Minimize Bundled Jars Nam Nguyen
8/10 RES-based Component Ayub Khan completed
8/6 Implement Representation Model Ayub Khan completed
8/23 Service Manager Integration Ayub Khan
8/15 Feature Polish Peter Liu
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo