|
Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
 Previous |
 Next |
|
Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
|
Previous |
Next |
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:
Migrating JSP pages from WebLogic Server to Oracle Application Server is straight forward and requires little or no code changes.
WebLogic Server 8.1 is compliant with Sun Microsystem's JavaServer Page specifications, version 1.2. Oracle Application Server 10g Release 3 (10.1.3) is compliant with JSP 2.0 and is backward compatible to version 1.2. Hence, JSP pages written to the standard version 1.2 specification should work correctly in Oracle Application Server 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".
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.
Table 4-1 JSP feature comparison
| Feature | Oracle Application Server 10g Release 3 (10.1.3) | WebLogic Server 8.1 |
|---|---|---|
|
JSP Version Support |
2.0 |
1.2 |
|
Basic JSP Tag Libraries |
Yes |
Yes |
|
Advanced JSP Tag Libraries |
Yes |
No |
|
JSP Source Level Debugging |
Yes |
No |
|
ASP to JSP Source Level Conversion |
Yes |
No |
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 Containers for J2EE JSP Tag Libraries and Utilities Reference.
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, SQLJ, and expression language. 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 (non exhaustively) connection pooling tags, XML tags, EJB tags, file access tags, email tags, caching tags, OracleAS Personalization tags, OracleAS Ultrasearch tags, a custom tag library for SQL functionality, and support for JSTL (JavaServer Pages Standard Tag Library). 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 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.
The following sections provide a summary of Edge Side Includes for Java (JESI) Tags and Web Object Cache Tags. See the Oracle Containers for J2EE JSP Tag Libraries and Utilities Reference for a discussion of other available 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.
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 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 JSP from WebLogic Server is straightforward and involves configuration, packaging (into a WAR file), and deployment tasks (to appropriate deployment directory). These tasks can be performed manually or by using Oracle JDeveloper.
In cases where proprietary tag libraries are used, they can be ported to either Oracle proprietary tags (see Section 4.4.1) or custom tags can be created to replace them.
Known JSP Migration Caveats
The following are known issues for migrating JSPs from WebLogic Server:
WebLogic tags are located in the tagext directory.
The WebLogic cache tag library is not supported. Use OC4J's Web Object Cache tag library (see Section 4.4.1.1).
The following WebLogic-specific tags and properties have to be migrated:
<process> (see Section 4.4.1.2)
<repeat> (see Section 4.4.1.3)
<%@ page extends=Ó..Ó %>
This directive should be replaced with <%@ page import=Ó..Ó %> .
htmlKona (see Section 4.5)
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.
|
Note: Application Server Control Console should be used to deploy any type of applications including JSPs. But for the purpose of illustration, the JSP files in the following example are copied manually without using Application Server Control Console. |
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
| Step | Description | Process |
|---|---|---|
|
1 |
Start an instance of OC4J, if none are currently running. |
Use the Oracle Enterprise Manager 10g Application Server Control Console administration Web pages or the following opmnctl @instance startproc ias-component=OC4J |
|
2 |
Copy the JSP page to the appropriate directory |
Copy In UNIX, from: <BEA_HOME>/weblogic81/samples/server/examples/src/ examples/jsp/
to: <ORACLE_HOME>/j2ee/home/default-web-app/
In Windows, from: <BEA_HOME>\weblogic81\samples\server\examples\src\ examples\jsp\
to: <ORACLE_HOME>\j2ee\home\default-web-app\
|
|
4 |
Request the JSP page from your Web browser |
From a Web browser, request the JSP page through the URL: http://<hostname>:7777/j2ee/HelloWorld.jsp
or http://<hostname>:7777/j2ee/ShowDate.jsp
where |
|
See Also: Oracle Containers for J2EE Support for JavaServer Pages Developer's Guide and Oracle Application Server Containers for J2EE User's Guide for detailed information on configuring and deploying JSP pages. |
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 7.0 to OC4J. (Note that this example is not available in WebLogic Server 8.1.)
Table 4-3 Migrating a Custom JSP Tag Library from WebLogic Server 7.0
| Step | Description | Process |
|---|---|---|
|
1 |
Copy the tag library file to the appropriate directory |
Copy UNIX: <BEA_HOME>/weblogic700/samples/ server/src/examples/jsp/tagext/counter/
Windows: <BEA_HOME>\weblogic700\samples\ server\src\examples\jsp\tagext\counter\
of your WebLogic Server installation to the following directory in your OC4J installation: UNIX: <ORACLE_HOME>/j2ee/home/ default-web-app/WEB-INF/
Windows: <ORACLE_HOME>\j2ee\home\ default-web-app\WEB-INF\
|
|
2 |
Copy the JSP file that uses the tag library to the appropriate directory |
Copy UNIX: <BEA_HOME>/weblogic700/samples/ server/src/examples/jsp/tagext/counter/
Windows: <BEA_HOME>\weblogic700\samples\ server\src\examples\jsp\tagext\counter\
of your WebLogic Server installation to the following directory in your OC4J installation: UNIX: <ORACLE_HOME>/j2ee/home/default-web-app/
Windows: <ORACLE_HOME>\j2ee\home\default-web-app\
|
|
3 |
Copy any class files required by the tag library and used by the JSP file to the appropriate directory |
Copy UNIX: <BEA_HOME>/weblogic700/samples/server/ config/examples/applications/ examplesWebApp/WEB-INF/classes/ examples/jsp/tagext/counter/
Windows: <BEA_HOME>\weblogic700\samples\server\ config\examples\applications\ examplesWebApp\WEB-INF\classes\ examples\jsp\tagext\counter\
of your WebLogic Server installation to the following directory in your OC4J installation: UNIX: <ORACLE_HOME>/j2ee/home/ default-web-app/WEB-INF/ classes/examples/jsp/tagext/counter/
Windows: <ORACLE_HOME>\j2ee\home\ default-web-app\WEB-INF\ classes\examples\jsp\tagext\counter\
Note that these |
|
4 |
Copy image files used by the JSP file |
Copy the directory containing the image files from UNIX: <BEA_HOME>/weblogic700/samples/server/ src/examples/jsp/tagext/counter/ images/numbers/
Windows: <BEA_HOME>\weblogic700\samples\server\ src\examples\jsp\tagext\counter\ images\numbers\
of the WebLogic Server installation to the following directory in your OC4J installation: UNIX: <ORACLE_HOME>/j2ee/home/ default-web-app/images/numbers/
Windows: <ORACLE_HOME>\j2ee\home\ default-web-app\images\numbers\
Note that you may have to create the |
|
5 |
Modify the appropriate Web application deployment descriptor and save the changes |
Add the directive entry below to the UNIX: <ORACLE_HOME>/j2ee/home/ default-web-app/WEB-INF/
Windows: <ORACLE_HOME>\j2ee\home\ default-web-app\WEB-INF\
Directive entry ( <taglib> <taglib-uri> counter </taglib-uri> <taglib-location> /WEB-INF/counter.tld </taglib-location> </taglib> |
|
6 |
Restart or start the OC4J instance, if it is not currently running. |
Go to opmnctl @instance restartproc ias-component=OC4J |
|
7 |
Request the JSP file from your Web browser |
From your Web browser, access the URL http://
where |
|
See Also:
|
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.
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.
|
See Also: Oracle Containers for J2EE JSP Tag Libraries and Utilities Reference for detailed information on Web Object Cache tags and JESI tags. |
process Tag
OC4J does not have an exact equivalent for the process tag. The closest option is to substitute it with scriptlet if statements, the Apache Struts <logic:exists> tag, or JSTL tags. Alternatively, you could write Java code to implement the tag.
htmlKona is an API available with WebLogic Server. It is used for creating and manipulating HTML programmatically. htmlKona was made available before JSP specifications were available. Since htmlKona is proprietary to WebLogic, Oracle Application Server does not support it, and the recommended approach to migrate applications using htmlKona to Oracle Application Server is to replace the use of htmlKona with JSPs. If there is a strong need to manipulate HTML programatically, Oracle JDeveloper provides UMX and other features to match and exceed the functionalities of htmlKona.
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.
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
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:
|
Note: Ensure that the<ORACLE_HOME>/jdk/bin is set in the path environment variable so that the correct Java executable is used for ojspc.
|
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 (for UNIX)
<ORACLE_HOME>/j2ee/home/application-deployments/default/ defaultWebApp/persistence/_pages/_examples/_jsp/
or, for Windows:
<ORACLE_HOME>\j2ee\home\application-deployments\default\ defaultWebApp\persistence\_pages\_examples\_jsp\
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.
|
See Also: The chapter JSP Translation and Deployment in Oracle Containers for J2EE Support for JavaServer Pages Developer's Guide. |
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.
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 Containers for J2EE Support for JavaServer Pages Developer's Guide.
