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

- Previous: Migrating Enterprise EJB Modules
- Next: Migrating Proprietary Extensions

# Migrating Enterprise Applications

According to the J2EE specifications, an enterprise application is an EAR file, which must have the following structure:

- A `META-INF/` directory containing the XML deployment descriptor of the J2EE application called `application.xml`

- The JAR and WAR archive files for the EJB modules and Web module of the enterprise application, respectively

In the application deployment descriptor, the modules that make up the enterprise application and the Web application’s context root are defined.

Application server 6.x and the Application Server 8.1support the J2EE model wherein applications are packaged in the form of an enterprise archive (EAR) file (extension `.ear`). The application is further subdivided into a collection of J2EE modules, packaged into Java archives (JAR files, which have a `.jar` file extension) and EJBs and Web archives (WAR files, which have a `.war` file extension) for servlets and JSPs.

It is essential to follow the steps listed here before deploying an enterprise application:

## To Build an EAR File

##### Steps

1. Package EJBs in one or more EJB modules.

2. Package the components of the Web application in a Web module.

3. Assemble the EJB modules and Web modules in an enterprise application module.

4. Define the name of the enterprise application’s root context, which will determine the URL for accessing the application.

   The Application Server uses a newer class loader hierarchy than Application Server 6.x does. In the new scheme, for a given application, one class loader loads all EJB modules and another class loader loads Web modules. These two are related in a parent child hierarchy where the JAR module class loader is the parent module of the WAR module class loader. All classes loaded by the JAR class loader are available/accessible to the WAR module but the reverse is not true. If a certain class is required by the JAR file as well as the WAR file, then the class file must be packaged inside the JAR module only. If this guideline is not followed it can lead to class conflicts.

## Application Root Context and Access URL

There is a major ”difference between Application Server 6.x and the Application Server, concerning the applications access URL (root context of the application’s Web module. If `AppName` is the name of the root context of an application deployed on a server called `hostname`, the access URL for this application will differ depending on the application server used:

- With Application Server 6.x, which is always used jointly with a Web front-end, the access URL for the application takes the following form (assuming the Web server is configured on the standard HTTP port, 80):

      http://<hostname>/NASApp/AppName/

- With the Application Server, the URL takes the form:

      http://<hostname>:<portnumber>/AppName/

The TCP port used as default by Application Server is port 8080.

Although the difference in access URLs between Application Server 6.x and the Application Server might appear minor, it can be problematic when migrating applications that make use of absolute URL references. In such cases, it is necessary to edit the code to update any absolute URL references so that they are no longer prefixed with the specific marker used by the Web Server plug-in for Application Server 6.x.

## Applications With Form-based Authentication

Applications developed on Application Server 6.5 that use form-based authentication can pass the request parameters to the Authentication Form or the Login page. The Login page could be customized to display the authentication parameters based on the input parameters.

For example:

`http://gatekeeper.uk.sun.com:8690/NASApp/test/secured/page.jsp?arg1=test&arg2=m`

Application Server 8.1 does not support the passing of request parameters while displaying the Login page. The applications that uses form-based authentication, which passes the request parameters can not be migrated to Application Server 8.1. Porting such applications to Application Server 8.1 requires significant changes in the code. Instead, you can store the request parameter information in the session, which can be retrieved while displaying the Login page.

The following code example demonstrates the workaround:

Before changing the code in 6.5:

    ---------index-65.jsp -----------
    <%@page contentType="text/html"%>
    <html>
    <head><title>JSP Page</title></head>
    <body>
    go to the <a href="secured/page.htm">secured a rea</a>
    </body>
    </html>
    ----------login-65.jsp--------------
    <%@page contentType="text/html"%>
    <html>
    <head> </head>
    <body>
    <!-- Print login form -->
    <h3>Parameters</h3><br>
    out.println("arg1 is " + request.getParameter("arg1"));
    out.println("arg2 is " + request.getParameter("arg2"));
    </body>
    </html>

After changing the code in Application Server 8.1:

    ---------index-81.jsp -----------
    <%@page contentType="text/html"%>
    <html>
    <head><title>JSP Page</title></head>
    <body>
    <%session.setAttribute("arg1","test"); %>
    <%session.setAttribute("arg2","me"); %>
    go to the <a href="secured/page.htm">secured area</a>
    </body>
    </html>

The `index-81.jsp` shows how you can store the request parameters in a session.

    ----------login-81.jsp--------------
    <%@page contentType="text/html"%>
    <html>
    <head> </head>
    <body>
    <!-- Print login form -->
    <h3>Parameters</h3><br>
    <!--retrieving the parameters from the session -->
    out.println("arg1 is"+(String)session.getAttribute("arg1"));
    out.println("arg2 is” + (String)session.getAttribute("arg2"));
    </body>
    </html>

- Previous: Migrating Enterprise EJB Modules
- Next: Migrating Proprietary Extensions

- © 2010, Oracle Corporation and/or its affiliates