Migrate Web applications

While version 2.3 of the servlet specification and version 1.2 of the JavaServer Pages (JSP) specification are supported by WebSphere Application Server Express, versions 1.1 and 1.2 of the JavaServer Pages (JSP) specification are compatible and the difference between versions 2.2 and 2.3 of the servlet specification are minor. There are behavioral differences between the Java 2 Enterprise Edition (J2EE) 1.2 and 1.3 specifications.

Servlet migration might be a concern for your application if it has these characteristics:

It extends a PageListServlet that relies on configuration information in the servlet configuration XML file.
It uses a servlet to generate HTML output.
It calls the response.sendRedirect() method for a servlet by using the encodeRedirectURL function or by running it within a non-context root.
URIs at WebSphere Application Server - Express are case sensitive when handled by the file serving servlet. That is, when a request is sent to WebSphere Application Server to serve a file, the filename as it exists in the file system must match the case as is specified on the URI. This is also true starting with WebSphere Application Server Version 3.5.6 and beyond. If you are migrating a Web application from WebSphere Application Server 3.5.5 (or earlier), you need to ensure your Web applications use proper case when referencing file served files.
It is migrated from WebSphere Application Server Version 3.5, and it uses ServletContext attributes. Such attributes are accessed via the ServletContext.getAttribute() API during servlet execution. Websphere Application Server Version 3.5 provided these ways of setting ServletContext attributes:
- Using the ServletContext.setAttribute( ) - a runtime servlet API available at V2.1 and v2.2.
- By configuring at the administrative console by clicking on a the Advanced tab for a web application and updating the name and value pair for the Attributes field. Such attributes are set at application server or web application startup.

The second method of setting ServletContext methods is no longer available at WebSphere Application Server - Express, thus attributes can only be be set during servlet runtime using ServletContext.setAttribute( ) - the first method above. If your web application at Version 3.5 relied on setting ServletContext attributes using the second method, you should convert over to use getInitParameter( ) and getInitParameterNames( ), which are new servlet APIs as of v2.2.

The other internal servlets that are affected by the WebSphere Application Server - Express package name change are DefaultErrorReporter and AutoInvoker. Use the WebSphere Application Server - Express package name, com.ibm.ws.webcontainer.servlet.DefaultErrorReporter and com.ibm.ws.webcontainer.servlet.AutoInvoker for these servlets.

Web application migration tips

Some tips for migrating your Web applications include the following:

Set a content type if your servlet generates HTML output.

The default behavior of the Web container changed in WebSphere Application Server - Express. If the servlet developer does not specify a content type in the servlet then the container is forbidden to set one automatically. Without an explicit content type setting, the content type is set to null. The Netscape browser displays HTML source as plain text with a null content type setting.

To resolve this problem, do one of the following:

Explicitly set a content type in your servlet.
Open the WAR file and enable the autoResponseEncoding static file setting.

Set the Java environment variable, com.ibm.websphere.sendredirect.compatibility, to true if you want your URLs interpreted relative to the application root.

Import your classes if your application uses unnamed packages. According to the JSP 1.2 specification, and unnamed package should not be used unless the class is explicitly imported.

For example, if myServletClass is in the unnamed package, and you reference it in a <jsp:useServlet> tag, then you must explicitly import myServletClass with the page directive import attribute, as shown in the following example:

  <%@page import="myServletClass" %>
  ...
  <jsp:useServlet id="myServlet" class="myServletClass" scope="session"/>

In WebSphere Application Server - Express, the JSP engine creates JSP page implementation classes in the org.apache.jsp package. If a class in the unnamed package is not explicitly imported, then the javac compiler assumes the class is in package org.apache.jsp, and the compilation fails.

Note: Avoid using the unnamed package altogether because in Java 2 SDK 1.4, the compiler does not accept simple names (or unnamed packages) in the import statements.

Issues concerning the migration of JSPs and Servlets
When you migrate from Version 3.5 to WebSphere Application Server - Express, servlets and JSPs that are installed in the default Web application (default_app) are not migrated by the WebSphere Application Server migration tools. Options to migrate application components that are installed in the default_app Web application are as follows:

Install the servlets and JSPs to a different Web application. The WebSphere Application Server migration tools will then migrate these application components.
Use the WebSphere Application Server migration tools to migrate the resources used by the servlets and JSPs that are installed in the default Web application. The migration tools will migrate resources, such as data sources and virtual hosts. After you have migrated the resources, manually migrate the servlets and JSPs without using the WebSphere Application Server migration tools.

If you use the IBM <tsx:dbquery> tag in any of your JSPs, you might need to make additional updates. In Version 5.0, the behavior of the tag's id attribute changed. In previous versions, the id attribute specified the object name of the bean, but now refers to the bean's key name that is stored in the page context. For more information, see <tsx:dbquery> in the Application Development topic.