Browse Prior Art Database

An Efficient Method of Developing/Debugging JSP Pages of Web/Portal Applications Using IDE Disclosure Number: IPCOM000035502D
Original Publication Date: 2005-Jan-21
Included in the Prior Art Database: 2005-Jan-21
Document File: 2 page(s) / 60K

Publishing Venue



The advances in Web/Portal technology has made it necessary to have a convenient and powerful IDE for application development. Vendors have now developed various kinds of tooling to assist application development. However, due to the nature of Web/Portal application deployment and given that the Web page generation process takes a long time, especially for a large application. Quite often it takes a developer tens of seconds or even minutes to go through one JavaServer Pages (JSP) change-test. The longer the JSP change-test process cycle, the more time it takes for the developers to complete their task. This disclosure publication addresses a new process that helps to speed up the JSP change-test process that can be used to improve a developers? productivity.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

An Efficient Method of Developing /Debugging JSP Pages of Web/Portal Applications Using IDE

The common steps of the JSP change-test cycle are summarized below:

1) Export the project to a WAR file;
2) Deploy the WAR file to the server (e.g. update an application in WebSphere Portal Server (WPS));
3) Compile the new JSP;
4) Load the application, go through all the application process logic including retrieve data from the backend, and finally generate the responding (HTML) page;
5) Test the JSP.

This process take minutes using WebSphere Studio Application Developer (WSAD)/ (WPS). A better solution with WSAD is to run a local test server to avoid steps 1) and 2). By setting the JSP reloading attribute of the test server to true, WSAD can just copy the modified JSP to the test server to avoid exporting and updating the entire application. However, with this improvement steps 3) and 4) are still needed and that could take some time to finish. This solution only works when the local test server is used. There are many situations in which the developer has to use a remote test server. When a developer uses a remote test server, steps 1 - 4 of the change-test cycle must be executed each time they update the JSP .

The solution disclosed in this publication enables a developer to by-pass steps 1-4 and thus dramatically reduces the JSP change-test cycle.

A JSP contains 4 basic types of code: JSP tags, Java code, HTML tags and JavaScript. A JSP must be recompiled if any changes are made to JSP tags or Java code. However, if changes are made to HTML tags...