Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate web applications > Migrate web application components


Migrate web application components from WAS v5.x

Migration of web applications deployed in previous versions of WAS is usually not necessary. Versions 2.2 and later of the Java Servlet specification and versions 1.2 and 1.4 of the JSP specifications are still supported unless the behavior was changed in the Servlet 3.0 or JSP 2.1 specifications. These changes are generally available in more detail in their corresponding specification.

Servlet migration might be a concern if the application:


JSP migration might be a concern if the application references JSP page implementation classes in unnamed packages, or if you install WAS v4.x EAR files (deployed in v4.x with the JSP Precompile option), in v5.x. You need to recompile all JSP pages when migrating from WAS v5.x.

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:

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 using 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 dependant on. Refer the Modifying the default web container configuration topics for details on how to modify this custom property. Because this property is a global setting, consider the effect on other applications.


Assembly tools
Hot deployment and dynamic reloading
Migrate to Java Platform, Standard Edition (Java SE) 6
Modify the default web container configuration


Related


Web applications: Resources for learning
Configure JVM sendRedirect calls to use context root
Rational Application Developer documentation

+

Search Tips   |   Advanced Search