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.. Describes the version behavior for each version. 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
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.
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.0.1 EAR files (deployed in
Version 4.0.1 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.

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.
sptcfgFollow these steps if migration issues apply to your web application: