Migrate Web application components from WAS V5.x

 

 

Overview

Migration of Web applications deployed in WebSphere Application Server V5.x is usually not necessary; version 2.2 and 2.3 of the Java Servlet specification and version 1.2 and 1.4 of the JavaServer Pages specification are still supported unless the behavior was changed in Servlet 2.4 or JSP 2.0 Specifications.

Servlet migration might be a concern if your application:

• implements a WAS internal servlet to bypass a WAS V4.x single application path restriction

• extends a PageListServlet that relies on configuration information in the servlet configuration XML file

• calls the response.sendRedirect method for a servlet using the encodeRedirectURL function or executing within a non-context root

• depends on a default Content-Type response header being set or the behavior of a setContentType call after a getWriter call is made. The behavior is set by WAS version level using the Web container custom property com.ibm.ws.webcontainer.contenttypecompatibility with a value of V4, V5, or V6. The behavior for each version is described below.

  	V4	V5	V6
  Default Content-Type	text or html	text or html charset=<default_encoding>	none
  Append Charset on getWriter if the property does not exist on Content-Type	text or html	text or html	text/xml;
  Example: response.setCharacterEncoding("UTF-8"); response.setContentType("text/xml"); response.getWriter();			charset=UTF-8
  Remove charset from the Content-Type property if the setContentType property is called after getWriter with a ";charset=" portion	text or html	text or html	text or html
  Example: setContentType("text/html;charset=ISO-8859-7"); getWriter(); setContentType("text/xml;charset=UTF-8");

JSP migration might be a concern if your application references JSP page implementation classes in unnamed packages, or if you install WebSphere Application Server V4.x EAR files (deployed in V4.x with the JSP Precompile option), in V5.x. We need to recompile all JSP pages when migrating from WAS V5.x.

Follow these steps if migration issues apply to your Web application:

 

Procedure

1. If a migrated application references internal servlets, enabled or disabled the functionality through the IBM WebSphere Extensions XMI file, ibm-web-ext.xmi, located in each Web module WEB-INF directory or by using assembly tools. Examples of this are fileServing and serveServletsByClassName.

2. Use WAS V5.x package names for any WAS V4.x internal servlets, which are implemented in your application.

   To bypass the errors, and to enable the serving of static files from the root context, WAS V4.x users are advised to open a Web deployment descriptor editor using an assembly tool and select File serving enabled on the Extensions tab.

3. Add the Web container custom property, com.ibm.ws.webcontainer.contenttypecompatibility, with a value of V4, V5, or V6. The value is determined by which version the application is dependant on. See Modifying the default Web container configuration for details on how to modify this custom property. Because this property is a global setting, consider the effect on other applications.

---

Hot deployment and dynamic reloading
Migrating to Java 2 Standard Edition (J2SE) 5

 

Related Reference

Web applications: Resources for learning
Configure JVM sendRedirect calls to use context root

 

Related information

Migrating and coexisting