An Efficient Method of Developing/Debugging JSP Pages of Web/Portal Applications Using IDE
Original Publication Date: 2005-Jan-21
Included in the Prior Art Database: 2005-Jan-21
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.
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.