Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Upgrade and Migration Guide

- Previous: Migrating Java Server Pages and JSP Custom Tag Libraries
- Next: Migrating Web Application Modules

## Migrating Servlets

Application Server 6.x supports the Servlet 2.2 API. Sun Java System Application Server 8.1 supports the Servlet 2.4 API.

Servlet API 2.4 leaves the core of servlets relatively untouched. Most changes are concerned with adding new features outside the core.

The most significant features are:

- Servlets now require JDK 1.2 or later

- Filter mechanisms have been created

- Application lifecycle events have been added

- Internationalization support has been added

- Error and security attributes have been expanded

- HttpUtils class has been deprecated

- Several DTD behaviors have been expanded and clarified

These changes are enhancements and are not required to be made when migrating servlets from Servlet API 2.2 to 2.4.

However, if the servlets in the application use JNDI to access resources in the J2EE application (such as data sources or EJBs), some modifications might be needed in the source files or in the deployment descriptor.

These modifications are explained in detail in the following sections:

- Obtaining a Data Source from the JNDI Context

- Declaring EJBs in the JNDI Context

One last scenario might require modifications to the servlet code. Naming conflicts can occur with Application Server 6.x if a JSP page has the same name as an existing Java class. In this case, the conflict must be resolved by modifying the name of the JSP page in question. This in turn can mean editing the code of the servlets that call this JSP page. This issue is resolved in Application Server as it uses a new class loader hierarchy. In the new version of the application server, for a given application, one class loader loads all EJB modules and another class loader loads web module. As these two loaders do not talk with each other, there is no naming conflict.

### Obtaining a Data Source from the JNDI Context

To obtain a reference to a data source bound to the JNDI context, look up the data source’s JNDI name from the initial context object. The object retrieved in this way is then be cast as a DataSource type object:

    ds = (DataSource)ctx.lookup(JndiDataSourceName);

For detailed information, refer to section “Migrating JDBC Code.”

### Declaring EJBs in the JNDI Context

Please refer to section Declaring EJBs in the JNDI Context in Chapter 5, Migrating from EJB 1.1 to EJB 2.0.”

### Potential Servlets and JSP Migration Problems

The actual migration of the components of a Servlet / JSP application from Application Server 6.x to Application Server 8.1does not require any modifications to the component code.

If the Web application is using a server resource, a DataSource for example, the Application Server requires that this resource to be declared inside the `web.xml` file and, correspondingly, inside the `sun-web.xml` file. To declare a DataSource called `jdbc/iBank`, the `<resource-ref>` tag in the `web.xml` file is as follows:

    <resource-ref>
       <res-ref-name>jdbc/iBank</res-ref-name>
       <res-type>javax.sql.XADataSource</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>

The corresponding declaration inside the `sun-web.xml` file looks like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <! DOCTYPE FIX ME: need confirmation on the DTD to be used for this file
    <sun-web-app>
       <resource-ref>
          <res-ref-name>jdbc/iBank</res-ref-name>
          <jndi-name>jdbc/iBank</jndi-name>
       </resource-ref>
     </sun-web-app>

- Previous: Migrating Java Server Pages and JSP Custom Tag Libraries
- Next: Migrating Web Application Modules

- © 2010, Oracle Corporation and/or its affiliates