Migrating web application components from WebSphere Application Server Version 5.x

Migration of web applications that are deployed in previous versions of WebSphere® Application Server is not necessary. Versions 2.2 and later of the Java™ Servlet specification and versions 1.2 and 1.4 of the JavaServer Pages (JSP) specifications are still supported unless the behavior was changed in the Servlet 3.1 or JSP 2.3 specifications. These changes are generally available in more detail in their corresponding specification.

About this task

Servlet migration might be a concern in the following instances:

  • Implements a WebSphere Application Server internal servlet to bypass a WebSphere Application Server Version 4.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 by using the encodeRedirectURL function, or starting 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 WebSphere Application Server version level using the web container custom property com.ibm.ws.webcontainer.contenttypecompatibility with a value of V4, V5, V6, or V7. The behavior for each version is described in Table 1.
    Table 1. Web container custom properties.. The table describes custom property information in the first column. Each column after the first column describes the version behavior of a particular version. The versions described are version 4, version 5, version 6, and version 7.
    Custom property information Version 4 Version 5 Version 6 Version 7
    Default Content-Type text/html text/html; charset= <default_ encoding> none none
    Append Charset on getWriter if the property does not exist on Content-Type

    Example: response.setCharacterEncoding("UTF-8"); response.setContentType("text/xml"); response.getWriter();

    		 text/html text/html text/xml; charset=UTF-8 text/xml; charset=UTF-8
    Remove charset from the Content-Type property if the setContentType property is called after getWriter with a ";charset=" portion

    Example: setContentType("text/html;charset=ISO-8859-7"); getWriter(); setContentType("text/xml;charset=UTF-8");

    		 text/html text/html text/html text/xml; charset=ISO-8859-7

[AIX Solaris HP-UX Linux Windows][IBM i]JSP migration might be a concern if your application references JSP page implementation classes in unnamed packages, or if you install WebSphere Application Server Version 4.x EAR files (deployed in Version 4.x with the JSP Precompile option), in Version 5.x. You need to recompile all JSP pages when migrating from WebSphere Application Server Version 5.x.

Supported configurations: For IBM® extension and binding files, the .xmi or .xml file name extension is different depending on whether you are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:
  • For an application or module that uses a Java EE version prior to version 5, the file extension must be .xmi.
  • For an application or module that uses Java EE 5 or later, the file extension must be .xml. If .xmi files are included with the application or module, the product ignores the .xmi files.

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions.

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

Procedure

  1. IBM internal servlets are used to enable special behavior such as file serving and serving servlets by class name. If a migrated application references internal servlets, the best practice is to enable or disable the functionality through the IBM WebSphere extensions XMI file, ibm-web-ext.xmi, located in each web module WEB-INF directory or by using an assembly tool.
  2. If these configuration options are not viable, then verify that the package names for the following internal servlets match what is used in your version 7 web deployment descriptor.
    Feature Configuration Option Servlet Class
    Directory browsing directoryBrowsingEnabled="true" com.ibm.ws.webcontainer.servlet.DirectoryBrowsingServlet
    Auto mapping of servlet paths serveServletsByClassnameEnabled="true: com.ibm.ws.webcontainer.servlet.SimpleFileServlet
    File serving fileServingEnabled="true" com.ibm.ws.webcontainer.servlet.FilterProxyServlet
  3. Add the web container custom property, com.ibm.ws.webcontainer.contenttypecompatibility, with a value of V4, V5, V6, V7, and so on. The value is determined by the version that the application is dependent on.
    Refer to the Modifying the default web container configuration topics for details on how to modify this custom property. Because this property is a global setting, you must consider the effect on other applications.