Within these environments it is essential to group the different components of an application (servlets, JSP and HTML pages and other resources) together within an archive file (Java EE-standard Web application module) deploying it on the application server.
According to the Java EE specification, a Web application is an archive file (WAR file) with the following structure:
A root directory containing the HTML pages, JSP, images and other static resources of the application.
A META-INF/ directory containing the archive manifest file MANIFEST.MF containing the version information for the SDK used and, optionally, a list of the files contained in the archive.
A WEB-INF/ directory containing the application deployment descriptor (web.xml file) and all the Java classes and libraries used by the application, organized as follows:
JSP 2.0 specification contains many new features, as well as updates to the JSP 1.1 specification.
These changes are enhancements and are not required to migrate to JSP pages from JSP 1.1 to 2.0.
The implementation of JSP custom tag libraries in Application Server 6.x complies with the J2EE specification. Consequently, migrating JSP custom tag libraries to the Application Server Platform Edition 9does not pose any particular problem, nor require any modifications.
Application Server 6.x supports the Servlet 2.2 API. Sun Java System Application Server 9 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 Java EE 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:
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.
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.”
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>
Migrating applications from Application Server 6.x to Sun Java System Application Server 9 does not require any changes to the Java code or Java Server Pages. However, you must change the following files:
The Application Server adheres to J2EE 1.4 standards, according to which, the web.xml file inside a WAR file must comply with the revised DTD at http://java.sun.com/dtd/web-app_2_3.dtd. This DTD is a superset of the previous versions’ DTD, hence only the <! DOCTYPE definition needs to be changed inside the web.xml file, which is to be migrated. The modified <! DOCTYPE declaration looks like:
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
In Application Server Platform Edition 9, the name of this file is changed to sun-web.xml.
This XML file must declare the Application Server-specific properties and resources that are required by the Web application.
See Potential Servlets and JSP Migration Problems for information about important inclusions to this file.
If the ias-web.xml of the Application Server 6.5 application is present and does declare Application Server 6.5 specific properties, then this file needs to be migrated to Application Server standards. The DTD file name has to be changed to sun-web.xml. For more details, see URL http://wwws.sun.com/software/dtd/appserver/sun-web-app_2_4-1.dtd
Once you have made these changes to the web.xml and ias-web.xml files, the Web application (WAR file) can be deployed from the Application Server’s deploytool GUI interface or from the command line utility asadmin. The deployment command must specific the type of application as web.
Invoke the asadmin command line utility by running asadmin.bat file or the asadmin.sh script in the Application Server’s bin directory.
asadmin deploy -u username -w password -H hostname -p adminport --type web [--contextroot contextroot] [--force=true] [--name component-name] [--upload=true] filepath