4
Migrating JSP Pages

This chapter provides the information you need to migrate JavaServer pages from WebLogic Server to Oracle Application Server. It covers the migration of simple JSP pages, custom JSP tag libraries, and WebLogic custom tags.

This chapter contains these topics:

• Introduction

• Migrating a Simple JSP Page

• Migrating a Custom JSP Tag Library

• Precompiling JSP Pages

Introduction

Migrating JSP pages from WebLogic Server to Oracle Application Server is straight forward and requires little or no code changes.

Both application servers are fully compliant with Sun Microsystem's JavaServer Page specifications, version 1.1 and 1.2. All JSP pages written to the standard specification will work correctly and require minimal migration effort.

The primary tasks involved in migrating JSP pages to a new environment are configuration and deployment. The use of proprietary extensions and tag libraries will require additional tasks and complicate the migration effort.

The tasks involved in migrating JSP pages also depend on how the JSP pages have been packaged and deployed. JSP pages can be deployed as a simple JSP page, as a web application packaged with other resources in a standard directory structure (WAR file), or as a enterprise application archive (EAR) file. The migration of web applications in exploded directory format and WAR files is addressed in Chapter 3, "Migrating Java Servlets".

Differences Between WebLogic Server and Oracle Application Server JSP Implementations

Since both WebLogic Server and Oracle Application Server Containers for J2EE (OC4J) have implemented the same versions of the Java Server Pages specifications, there are no differences between the two in the core JSP specification areas. There are differences in areas outside the core specifications. These are listed in Table 4-1.

Each vendor provides their own custom JSP tags. WebLogic Server provides four specialized JSP tags that you can use in your JSP pages. OC4J also provides various JSP tags - Oracle JSP Markup Language (JML) Custom Tag Library, tags for XML and XSL integration, and several JSP utility tags. A comprehensive discussion of these tags can be found in Oracle Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference.

OC4J JSP Features

Oracle Application Server provides one of the fastest JSP engines on the market. Further, it also provides several value-added features and enhancements such as support for globalization and SQLJ. If you are familiar with Oracle9iAS 1.0.2.2, the first release of Oracle Application Server to include OC4J, there were two JSP containers: a container developed by Oracle and formerly known as OracleJSP and a container licensed from Ironflare AB and formerly known as the "Orion JSP container".

In Oracle Application Server, these have been integrated into a single JSP container, referred to as the "OC4J JSP container". This new container offers the best features of both previous versions, runs efficiently as a servlet in the OC4J servlet container, and is well integrated with other OC4J containers. The integrated container primarily consists of the OracleJSP translator and the Orion container runtime running with a new simplified dispatcher and the OC4J 1.0.2.2 core runtime classes. The result is one of the fastest JSP engines on the market with additional functionality over the standard JSP specifications.

OC4J JSP provides extended functionality through custom tag libraries and custom JavaBeans and classes that are generally portable to other JSP environments:

• Extended types implemented as JavaBeans that can have a specified scope

• JspScopeListener for event handling

• Integration with XML and XSL through custom tags

• Data-access JavaBeans

• The Oracle JSP Markup Language (JML) custom tag library, which reduces the level of Java proficiency required for JSP development

• OC4J JSP includes connection pooling tags, XML tags, EJB tags, file access tags, email tags, caching tags, OracleAS Personalization tags, OracleAS Ultrasearch tags, and a custom tag library for SQL functionality. WebLogic only has four: cache, process, repeat, and form validation.

• JESI (Edge Side Includes for Java) tags and Web Object Cache tags and API that work with content delivery network edge servers to provide an intelligent caching solution for web content (see the following sub-sections).

  See Also: Oracle Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference for detailed information on custom JSP tag libraries.

The OC4J JSP container also offers several important features such as the ability to switch modes for automatic page recompilation and class reloading, JSP instance pooling, and tag handler instance pooling.

Edge Side Includes for Java (JESI) Tags

OC4J provides fine-grained control allowing developers to cache fragments of JSP pages down to each individual tag - these can be cached in OracleAS Web Cache and are automatically invalidated and refreshed when a JSP changes. The technology behind this is Edge Side Includes (ESI), a W3C standard XML schema/markup language that allows dynamic content to be cached in a Web Cache or to be assembled in an edge network. By caching this dynamic content, it reduces the need to execute JSPs or Servlets, thereby improving performance, off loading the application servers, and reducing latency. JESI (JSP to ESI) tags are layered on top of an Edge Side Includes (ESI) framework to provide ESI caching functionality in a JSP application. JESI tags enable the user to break down dynamic content of JSP pages into cacheable components or fragments.

Web Object Cache Tags

The Web Object Cache is an Oracle Application Server feature that allows Web applications written in Java to capture, store, reuse, post-process, and maintain the partial and intermediate results generated by JSPs or Servlets. For programming interfaces, it provides a tag library (for use in JSP pages) and a Java API (for use in Servlets). Cached objects might consist of HTML or XML fragments, XML DOM objects, or Java serializable objects. By caching these objects in memory, various operations can be carried out on the cached objects including:

• Applying a different XSLT based on user profile or device characteristics on the stored XML

• Re-using a cached object outside HTTP, such as SMTP to send e-mail to clients.

Oracle JDeveloper and OC4J JSP Container

Oracle JDeveloper is integrated with the OC4J JSP container to support the full JSP application development cycle - editing, source-level debugging, and running JSP pages. It also provides an extensive set of data-enabled and web-enabled JavaBeans, known as JDeveloper web beans and a JSP element wizard which offers a convenient way to add predefined web beans to a page. JDeveloper also provides a distinct feature that is very popular with developers. It allows you to set breakpoints within JSP page source and can follow calls from JSP pages into JavaBeans. This is much more convenient than manual debugging techniques, such as adding print statements within the JSP page to output state into the response stream for display on browser or to the server log.

Migrating a Simple JSP Page

JSP pages do not require specific mappings as do HTTP servlets. To deploy a simple JSP page, you can copy the JSP page and any files required by the JSP page to the appropriate directories. No additional registrations are required.

The deployment process has been simplified in OC4J by providing a J2EE web application and various configuration files by default.

To determine the effort involved in migrating JSP pages, we selected and migrated example JSP pages provided with WebLogic Server. We chose examples that did not use proprietary extensions.

Table 4-2 presents the typical process for migrating a simple JSP page from WebLogic Server to OC4J.

Table 4-2 Migrating a Simple JSP Page  

dcmctl start -i <appsvr_instance_name> -ct 
oc4j -co home

Migrating a Custom JSP Tag Library

WebLogic Server and OC4J provide the ability to create and use custom JSP tags. The process used to deploy a custom JSP tag library is similar for both WebLogic Server and OC4J.

Tag libraries can be packaged and deployed as part of a web application, and are declared in a specific section of the web application deployment descriptor.

To determine the effort involved in migrating custom JSP tag libraries, we selected and migrated example JSP pages provided with WebLogic Server. We chose examples that did not use proprietary extensions.

Table 4-3 presents the typical process for migrating a JSP page that utilizes a custom JSP tag library from WebLogic Server to OC4J.

Table 4-3 Migrating a Custom JSP Tag Library  

<taglib>
  <taglib-uri>
   counter
  </taglib-uri>
  <taglib-location>
   /WEB-INF/counter.tld
  </taglib-location>
</taglib>

dcmctl restart|start -i <appsvr_instance_
name> -ct oc4j -co home

Migrating from WebLogic Custom Tags

If WebLogic custom tags are used extensively throughout your web application, then the best migration option is to use the WebLogic tag library by deploying it on OC4J. This option was discussed in the previous section, "Migrating a Custom JSP Tag Library". You can then migrate to the OC4J JSP tags if required.

If WebLogic custom tags are used sparingly throughout your web application, then the best migration option is to modify the JSP pages to use the OC4J JSP tag library. This option is discussed below.

WebLogic Server provides three specialized JSP tags for use in JSP pages. They are cache, process, and repeat.

WebLogic Server cache Tag

OC4J provides a superset of the WebLogic Server cache tag in the form of Web Object Cache Tags. These tags provide additional functionality over the WebLogic cache tag. Further, the Web Object Cache Tags of OC4J are well integrated with other tag libraries such as the XML tag library. For example, the cacheXMLObj tag is well integrated with OC4J's XML tags.

One feature which does not have direct functionality mapping is "async". However, Edge Side Includes (ESI) and Edge Side Includes for Java (JESI) can provide similar functionality to it.

WebLogic Server process Tag

OC4J does not have an exact equivalent for the process tag. The closest option is to use the jml:useForm and jml:if tags. from Oracle's JSP Markup Language (JML).

Alternatively, you could write Java code to implement the tag.

WebLogic Server repeat Tag

The OC4J equivalent for this tag is the jml:foreach tag. This tag provides the ability to iterate over a homogeneous set of values. The body of the tag is executed once per element in the set. This tag currently supports iterations over the following types of data structures:

• Java array

• java.util.Enumeration

• java.util.Vector

However, these tags do not cover data structures such as Iterators, Collections, and the keys of a hashtable.

For ResultSets and ResultSetMetaData, OC4J provides tags called the SQL Tags for Data Access. These tags provide functionality very similar to that provided by the WebLogic Server repeat tag. The dbNextRow tag is the tag that you are likely to be most interested in. This tag can be used to process each row of a result set obtained in a dbQuery tag and associated with the specified queryId. Place the processing code in the tag body, between the dbNextRow start and end tags. The code in the body is executed for each row of the result set.

Precompiling JSP Pages

JSP pages are compiled automatically by the JSP compiler. However, when testing and debugging JSP pages, you may want to access the JSP compiler directly.

The JSP compiler parses a .jsp file into a .java file. The standard Java compiler is then used to compile the .java file into a .class file.

Using the WebLogic Server JSP Compiler

To start the WebLogic Server JSP compiler, type the following command in your WebLogic Server command line environment:

java weblogic.jspc -options fileName

The fileName parameter refers to the name of the JSP page to be compiled. Options may be specified before or after the JSP page name. The following example demonstrates the use of the -d option to compile myFile.jsp into the destination directory weblogic/classes:

java weblogic.jspc -d /weblogic/classes myFile.jsp

Using the OC4J JSP Pre-translator

In addition to the standard jsp_precompile mechanism, OC4J provides a command-line utility called ojspc for pre-translating JSP pages.

Consider the example where the JSP page, HelloWorld.jsp, is located in the following OC4J default web application directory (copy the HelloWorld.jsp file from <ORACLE_HOME>/j2ee/home/default-web-app/, or the Windows equivalent, to this subdirectory):

UNIX:
<ORACLE_HOME>/j2ee/home/default-web-app/examples/jsp/

Windows:
<ORACLE_HOME>\j2ee\home\default-web-app\examples\jsp\

To pre-translate this JSP page, set your current directory to the application root directory, then, in ojspc, set the _pages directory as the output base directory using the -d option. This results in the appropriate package name and file hierarchy. To illustrate:

In UNIX (assume % is a UNIX prompt):

% cd j2ee/home/default-web-app
% ojspc -d ../application-deployments/default/defaultWebApp/persistence/_pages 
     examples/jsp/HelloWorld.jsp

In Windows (in a command prompt window and where Oracle is the Oracle Home for your Oracle Application Server installation):

C:\>cd Oracle\j2ee\home\default-web-app
C:\>ojspc -d ../application-deployments/default/defaultWebApp/persistence/_pages 
     examples/jsp/HelloWorld.jsp

The directory structure above specifies an application-relative path of examples/jsp/HelloWorld.jsp. The translated JSP can be found in
<ORACLE_HOME>/j2ee/home/application-deployments/default/
defaultWebApp/persistence/_pages/_examples/_jsp/ for UNIX

or

<ORACLE_HOME>\j2ee\home\application-deployments\default\
defaultWebApp\persistence\_pages\_examples\_jsp\ for Windows.

At execution time, the JSP container looks for compiled JSP files in the _pages subdirectory. The _examples/_jsp/ subdirectory would be created automatically by ojspc if run as in the above example.

Invoke the JSP page through the URL http://<hostname>:7777/j2ee/examples/jsp/HelloWorld.jsp. Notice that response time is faster than without pre-translating.

Standard JSP Pre-translation Without Execution (based on the JSP 1.1 specification)

You can specify JSP pre-translation, without execution, by enabling the standard jsp_precompile request parameter when invoking a JSP page from the browser. For instance, http://<hostname>:<port>/foo.jsp?jsp_precompile=true

Using the <ORACLE_HOME>/j2ee/home/default-web-app/HelloWorld.jsp file (or Windows equivalent) as an example, erase all the "_HelloWorld*" files in:

UNIX:
<ORACLE_HOME>/j2ee/home/application-deployments/default/
defaultWebApp/persistence/_pages/

Windows:
<ORACLE_HOME>\j2ee\home\application-deployments\default\
defaultWebApp\persistence\_pages\

Then, invoke the URL http://<hostname>:7777/j2ee/HelloWorld.jsp?jsp_precompile=true. The pre-translation is performed but the page does not appear on your browser. Check the _pages subdirectory for the translated files.

Configure the JSP Container for Execution with Binary Files Only

You can avoid exposing your JSP page source, for proprietary or security reasons, by pre-translating the pages and deploying only the translated and compiled binary files. JSP pages that are pre-translated, either from previous execution in an on-demand translation scenario or by using ojspc, can be deployed to any standard J2EE environment.

For further details, refer to the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide.