| Sun ONE Application Server 7, Enterprise Edition Migrating and Redeploying Server Applications Guide |
Chapter 3
Migrating from Sun ONE Application Server 6.x to Sun ONE Application Server 7This chapter describes the considerations and strategies that are needed when moving J2EE applications from Sun ONE Application Server 6.0 and 6.5 to the Sun ONE Application Server 7 product line.
This section also describes specific migration tasks at the component level.
The following topics are addressed:
About Sun ONE Application Server 6.0/6.5Sun ONE Application Server version 6.0 is a multi-platform application server based entirely on the J2EE 1.2 specification. Supported platforms include Windows NT and 2000, Solaris, AIX, and HP-UX.
In addition, Sun ONE Application Server 6.0 integrates with many Web servers through specific Web connector plug-ins that it ships with. These connectors enable it to be coupled with Sun ONE Web Server, Microsoft IIS, or Apache.
The Sun ONE Application Server 6.0/6.5 architecture is shown in the following figure.
Figure 3-1 Sun ONE Application Server 6.0/6.5 Architecture
As shown in the above figure, there are four internal servers, which are often called engines or processes. These processes are responsible for all the processing in the Sun ONE Application Server. The four internal servers of the Sun ONE Application Server 6.0/6.5 are:
Executive Server - provides most system services (some services are managed by the Administrative Server).
Administrative Server - provides system services for Sun ONE Application Server Administration and failure recovery.
Java Server - provides services to java applications.
C++ Server - components written in C++ are hosted in C++ server.
When a web server forwards requests to Sun ONE Application Server 6.0/6.5, the requests are first received by the Executive Server process (KXS). The KXS process forwards the request either to a Java Server process (KJS) or to a C++ Server process (KCS). A KJS process runs Java programming logic, whereas a KCS process runs C++ programming logic. Each KJS and KCS process maintains a specified number of threads and runs the programming logic to completion on those threads. The results are returned to the web server and sent on to the client browser.
Migrating Deployment DescriptorsThe following table summarizes the deployment descriptor migration mapping.
The J2EE standard deployment descriptors ejb-jar.xml, web.xml and application.xml are not modified significantly. However, the ejb-jar.xml deployment descriptor is modified to make it compliant with EJB 2.0 specification in order to make the application deployable on Sun ONE Application Server 7 EE.
Majority of the information required for creating sun-ejb-jar.xml and sun-web.xml comes from ias-ejb-jar.xml and ias-web.xml respectively. However, there is some information that is required and extracted from the home interface (java file) of the CMP entity bean, in case the sun-ejb-jar.xml being migrated declares one. This is required to build the <query-filter> construct inside the sun-ejb-jar.xml, which requires information from inside the home interface of that CMP entity bean. If this source file is not present during the migration time, the <query-filter> construct will get created, but with lots of missing information (which will manifest itself in the form of "REPLACE ME" phrases in the migrated sun-ejb-jar.xml).
Additionally, if the ias-ejb-jar.xml contains a <message-driven> element, then information from inside this element is picked up and used to fill up information inside both ejb-jar.xml and sun-ejb-jar.xml. Also, inside the <message-driven> element of ias-ejb-jar.xml, there is an element <destination-name>, which holds the JNDI name of the topic or queue to which the MDB should listen to. In Sun ONE Application Server 6.5, the naming convention for this jndi name is "cn=<SOME_NAME>". Since a JMS Topic or Queue with this name is not deployable on Sun ONE Application Server 7 EE, changes this to "<SOME_NAME>", and insert this information in the sun-ejb-jar.xml. This change must be reflected for all valid input files, namely, all .java, .jsp and .xml files. Hence, this change of JNDI name is affected globally across the application, and in case of non availability of some source files that contain reference to this jndi-name, you need to make the change manually in them so that the application becomes deployable.
Migration Issues From Sun ONE Application Server 6.x to 7This section describes the issues that will arise while migrating the main components of a typical J2EE application from Sun ONE Application Server 6.0 and 6.5 to Sun ONE Application Server 7.
The migration issues described in this section are based on an actual migration that was performed for a J2EE application called iBank, a simulated online banking service, from Sun ONE Application Server 6.0 and 6.5 to Sun ONE Application Server 7. This application reflects all aspects that comprise a traditional J2EE application.
The following sensitive points of the J2EE specification covered by the iBank application include:
- Servlets, especially with redirection to JSP pages (model-view-controller architecture)
- JSP pages, especially with static and dynamic inclusion of pages
- JSP custom tag libraries
- Creation and management of HTTP sessions
- Database access through the JDBC API
- Enterprise JavaBeans: Stateful and Stateless session beans, CMP and BMP entity beans.
- Assembly and deployment in line with the standard packaging methods of the J2EE application
The iBank application is presented in detail in Appendix A - iBank Application Specification.
Migrating J2EE ComponentsThe following migration processes are described in this section:
Migrating JDBC Code
With the JDBC API, there are two methods of database access:
Establishing Connections Through the DriverManager Interface
Although this means of accessing a database is not recommended, as it is obsolete and is not very effective, there may be some applications that still use this approach.
In this case, the access code will be similar to the following:
public static final String driver = "oracle.jdbc.driver.OracleDriver";
public static final String url = "jdbc:oracle:thin:tmb_user/tmb_user@iben:1521:tmbank";
Class.forName(driver).newInstance();
Properties props = new Properties();
props.setProperty("user", "tmb_user");
props.setProperty("password", "tmb_user");
Connection conn = DriverManager.getConnection(url, props);
This code can be fully ported from Sun ONE Application Server 6.0/6.5 to Sun ONE Application Server 7, as long as Sun ONE Application Server is able to locate the classes needed to load the right JDBC driver. In order to make the required classes accessible to the application deployed in Sun ONE Application Server 7, you should:
Modify the CLASSPATH by setting the path for the driver through the GUI of the admin server. Click the server instance “server1” and then click the tab “JVM Settings” from the right pane. Now click the option Path Settings and add the path in the classpath suffix text entry box. Once you make the changes, click “Save” and then apply the new settings. Restart the server to modify the configuration file, server.xml.
Using JDBC 2.0 Data Sources
Using JDBC 2.0 data sources to access a database provides performance advantages such as transparent connection pooling, enhances productivity by simplifying code and implementation, and provides code portability.
Using a data source in an application requires an initial configuration phase followed by a registration of the data source in the JNDI naming context of the application server. Once the data source is registered, the application will easily be able to obtain a connection to the database by retrieving the corresponding DataSource object from the JNDI context. The actions are described in the following topics:
Configuring a Data Source
In Sun ONE Application Server 6.0 data sources and their corresponding JDBC drivers are configured from the server's graphic administration console. Connection pools are managed automatically by the application server, and the administration tool can be used to configure their properties. With integrated type 2 JDBC drivers, the connection pooling properties are defined on a per-driver basis, and common to all data sources using a given driver.
On the other hand, for third-party JDBC drivers, connection pool properties are defined on a per-data source basis. Third-party JDBC drivers can be configured either from the administration tool, or from a separate utility (db_setup.sh in Sun Solaris, and jdbcsetup in Windows NT/2000). Moreover, the command line utility iasdeploy can be used to configure a data source from an XML file describing its properties. These utilities are all located in the /bin/ sub-directory of the Sun ONE Application Server installation root directory.
In Sun ONE Application Server 7, data sources can be configured from the server's graphic administration console or through the command line utility asadmin. The command line utility asadmin can be invoked by executing asadmin file in Solaris, available in Sun ONE Application Server 7 installation’s bin directory. At the asadmin prompt, use the following commands to create connection pool and JNDI resource.
The syntax for calling the asadmin utility to create a connection pool is as follows:
asadmin>create-jdbc-connection-pool -u username -w password -H hostname -p adminport [-s] [--instance instancename] --datasourceclassname classname [--steadypoolsize=8] [--maxpoolsize=32] [--maxwait=60000] [--poolresize=2] [--idletimeout=300] [--isconnectvalidatereq=false] [--validationmethod=auto-commit] [--validationtable tablename] [--failconnection=false] [--description text] [--property (name=value)[:name=value]*] connectionpoolid
For example:
asadmin>create-jdbc-connection-pool -u admin -w password -H cl1 -p 4848 –instance server1 --datasourceclassname oracle.jdbc.pool.OracleConnectionPoolDataSource --property (user-name=ibank_user):(password=ibank_user) oraclepool
Here JDBC connection pool ‘oraclepool’ for oracle database is created using database schema having the username ‘ibank_user’ and password ‘ibank_user’.
The syntax to create a JDBC resource is as follows:
asadmin>create-jdbc-resource -u username -w password -H hostname -p adminport [-s] [--instance instancename] --connectionpoolid id [--enabled=true] [--description text] [--property (name=value)[:name=value]*] jndiname
For example:
asadmin>create-jdbc-resource -u admin -w password -H cl1 -p 4848 --instance server1 --connectionpoolid oraclepool jdbc/IBANK
Here jdbc resource is created for the connection pool created above with the JNDI name ‘jdbc/IBANK’.
Here is the procedure to follow when registering a data source in Sun ONE Application Server 7 through graphical interface.
- Register the data source classname
- Place the archive (JAR or ZIP) for the data source class implementation in the /lib directory of the Sun ONE Application Server 7 installation directory.
- Modify the CLASSPATH by setting the path for the driver through the GUI of the admin server. Click at the server instance “server1” and then click at tab “JVM Settings”, now click at path settings and add the path at the classpath suffix column. Once you make the changes save it and then apply these new settings. Restart the server, which would modify the configuration file, server.xml.
- Register the data source
In Sun ONE Application Server 7, data sources and their corresponding JDBC drivers are configured from the server's graphic administration interface.
The left pane is a tree view of all items you can configure in the Sun ONE Application Server. Click on the item Connection pool at the left pane, the right pane would display the page associated with it where the relevant entries can be made.
Figure 3-2 Configuring Connection Pool through GUI
Similarly now click at the item Data source, right pane would show the entries required for data source setup.
Sun ONE Application Server 7 specific deployment descriptor sun-web.xml has to be modified accordingly.
For example if a new data source is configured for the iBank Application, the sun-web.xml would have following entries.
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 'Http://localhost:8000/sun-web-app_2_3.dtd'>
<sun-web-app>
<resource-ref>
<res-ref-name>jdbc/iBank</res-ref-name>
<jndi-name>jdbc/iBank</jndi-name>
<default-resource-principal>
<name>ibank_user</name>
<password>ibank_user</password>
</default-resource-principal>
</resource-ref>
</sun-web-app>
Looking Up the Data Source Via JNDI To Obtain a Connection
To obtain a connection from a data source, the process is as follows:
- Obtain an initial JNDI context
- Obtain a reference to the data source by using a JNDI lookup
- Obtain a connection using this reference
- Obtaining the initial JNDI context
To guarantee portability between different environments, the code used to retrieve an InitialContext object (in a servlet, in a JSP page, or an EJB), should be simply, as follows:
InitialContext ctx = new InitialContext();
- Obtaining a data source reference
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 should then be cast as a DataSource type object:
ds = (DataSource)ctx.lookup(JndiDataSourceName);
- Obtaining the connection
This operation is very simple, and requires the following line of code:
conn = ds.getConnection();
Sun ONE Application Server 6.0/6.5 and 7 both follow the above technique for obtaining a connection form data source. So to summarize migration does not require any modification to be made to the code.
Migrating Java Server Pages and JSP Custom Tag Libraries
Sun ONE Application Server 6.0/6.5 complies with the JSP 1.1 specification and Sun ONE Application Server 7 complies with the JSP 1.2 specification.
JSP 1.2 specification contains many new features as well as corrections and clarifications of areas that were not quite right in JSP 1.1 specification.
The most significant changes are
- JSP 1.2 is based on Servlet 2.3 and Java 2. JSP 1.2 applications will not run on platforms that only support JDK 1.1. JSP 1.2 is backward compatible with JSP 1.1, so JSP 1.1 application should run without any tweaking in a JSP 1.2 complaint container.
- The definition of XML syntax for a JSP page has been finalized. So a JSP 1.2 complaint container must accept files in both JSP 1.1 format and the new XML format called as JSP Document.
- Tag libraries can make use of Servlet 2.3 event listeners.
- A new type of validation has been added, for the tag libraries, which validates JSP pages.
- New options for tag library distribution and deployment have been added.
These changes are basically enhancements and are not required to be made, while migrating JSP pages from JSP API 1.1 to 1.2.
The implementation of JSP custom tag libraries in Sun ONE Application Server 6.0 and 6.5 complies with the J2EE specification. Consequently, migration of JSP custom tag libraries to Sun ONE Application Server 7 does not pose any particular problem, nor require any modifications to be made.
Migrating Servlets
Sun ONE Application Server 6.0 and 6.5 support the Servlet 2.2 API whereas Sun ONE Application Server 7, supports the Servlet 2.3 API.
Servlet API 2.3 actually 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
- A filter mechanism has been created
- Application lifecycle events have been added
- New internationalization support has been added
- New error and security attributes have been added
- The HttpUtils class has been deprecated
- Several DTD behaviors have been expanded and clarified
These changes are basically enhancements and are not required to be made while migrating servlets from Servlet API 2.2 to 2.3.
However, if the servlets in the application use JNDI to access resources of the J2EE application (such as data sources, EJBs, and so forth), some modifications may be needed in the source files or in the deployment descriptor.
These modifications are explained in detail in the following sections:
One last scenario may mean modifications are required in the servlet code, naming conflicts may occur with Sun ONE Application Server if a JSP page has the same name as an existing Java class. In this case, the conflict should be resolved by modifying the name of the JSP page in question, which may then mean editing the code of the servlets that call this JSP page. This issue is resolved in Sun ONE Application Server 7 as it uses new class loader hierarchy as compared to Sun ONE Application Server 6.0/6.5. In this new scheme, 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 would be 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 should then be cast as a DataSource type object:
ds = (DataSource)ctx.lookup(JndiDataSourceName);
For detailed information, refer to section “Migrating JDBC Code” in the previous pages.
Declaring EJBs in the JNDI Context
Please refer to section Declaring EJBs in the JNDI Context from "Migrating from the Enterprise Java Beans 1.1 Specification to Enterprise Java Beans 2.0".
EJB Migration
As mentioned in Migrating to Sun ONE Application Server 7, Enterprise Edition Overview, while Sun ONE Application Server 6.0 and 6.5 support the EJB 1.1 specification, Sun ONE Application Server 7 also supports the EJB 2.0 specification. The EJB 2.0 specification introduces the following new features and functions to the architecture:
Although the EJB 1.1 specification will continue to be supported in Sun ONE Application Server 7, the use of the EJB 2.0 architecture is recommended to leverage its enhanced capabilities.
For detailed information on migrating from EJB 1.1 to EJB 2.0, please refer to Appendix C, "Migrating from the Enterprise Java Beans 1.1 Specification to Enterprise Java Beans 2.0."
EJB Changes Specific to Sun ONE Application Server 7
Migrating EJB’s from Sun ONE Application server 6.0/6.5 to Sun ONE Application Server 7 would not require any changes in the EJB code. The following DTD changes are required.
Session Beans
- The <!DOCTYPE> definition should be modified to point to the latest DTDs with J2EE standard DDs, such as ejb-jar.xml.
- Replace ias-ejb-jar.xml file with the modified version of this file, named sun-ejb-jar.xml,created manually according to the DDs. For more details, see, http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-0.dtd
- In sun-ejb-jar.xml, the JNDI name for all the EJB’s should prepend ‘ejb/’ in all the JNDI names. This is required as, in Sun ONE Application Server 6.5, the JNDI name of the EJB could only be ejb/<ejb-name> where <ejb-name> is the name of the EJB as declared inside ejb-jar.xml.
Entity Beans
- The <!DOCTYPE> definition should be modified to point to the latest DTDs with J2EE standard DDs, such as ejb-jar.xml.
- Insert <cmp-version> tag with the value 1.1 for all CMPs in ejb-jar.xml.
- Replace all the <ejb-name>-ias-cmp.xml files with the manually created sun-cmp-mappings.xml file. For more information, see http://www.sun.com/software/sunone/appserver/dtds/sun-cmp_mapping_1_0.dtd
- Generate dbschema by using the capture-schema utility in the Sun ONE Application Server 7 installation’s bin directory and place it above META-INF folder for Entity beans.
- ias-ejb-jar.xml should be replaced with its new version, named sun-ejb.jar.xml, in Sun ONE Application Server 7.
- In Sun ONE Application Server 6.5, the finders sql was directly embedded inside the <ejb-name>-ias-cmp.xml. In Sun ONE Application Server 7 this has changed such that, now mathematical expressions are used to declare the <query-filter> for the various finder methods.
Message Driven Beans
Sun ONE Application Server 7, Enterprise Edition provides seamless Message Driven Support through the tight integration of Sun ONE Message Queue with the Sun ONE Application Server 7, Enterprise Edition, providing a native, built-in JMS Service.
This installation provides Sun ONE Application Server with a JMS messaging system that supports any number of Sun ONE Application Server instances. Each server instance, by default, has an associated built-in JMS Service that supports all JMS clients running in the instance.
Both container-managed and bean-managed transactions as defined in the Enterprise JavaBeans Specification, v2.0 are supported.
Message Driven Bean support in iPlanet Application Server was restricted to developers, and used many of the older proprietary APIs. Messaging services were provided by iPlanet Message Queue for Java 2.0. An LDAP directory was also required under iPlanet Application Server to configure the Queue Connection Factory object.
The QueueConnectionFactory, and other particulars required to configure Message Driven Beans in Sun ONE Application Server should be specified in the ejb-jar.xml file.
For more information on the changes to deployment descriptors, see "Migrating Deployment Descriptors." For information on Message Driven Bean implementation in Sun ONE Appserver 7, see Sun ONE Application Server 7, Enterprise Edition, Developer’s Guide to Enterprise Java Bean Technology.
Migrating Web ApplicationsSun ONE Application Server 6.0 and 6.5 support servlets (Servlet API 2.2), and JSPs (JSP 1.1). Sun ONE Application Server 7 on the other hand supports servlets (Servlet API 2.3) and JSPs (JSP 1.2).
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 (J2EE-standard Web application module) before you can deploy it on the application server.
According to the J2EE 1.3 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:
Migrating Web Application Modules
Migrating applications from Sun ONE Application server 6.0/6.5 to Sun ONE Application Server 7 would not require any changes in the Java/JSP code. The following changes are, however, still required.
Sun ONE Application Server 7 adheres to J2EE 1.3 standards, according to which, the web.xml file inside a WAR should adhere to the revised DTD available at http://java.sun.com/dtd/web-app_2_3.dtd. This DTD fortunately, is a superset of the previous versions’ DTD, hence only the <! DOCTYPE definition needs to be changed inside the web.xml, which is to be migrated. The modified <! DOCTYPE declaration should look 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 Sun ONE Application Server 7 the name of this file is changed to sun-web.xml.
This XML file is required to declare the Sun ONE Application Server 7 specific properties/resources that will be required by the web application.
Note: See the next section for some important inclusions to this file.
If the ias-web.xml of the Sun ONE Application Server 6.5 application is present and does declare Sun ONE Application Server 6.5 specific properties, then this file needs to be migrated to Sun ONE Application Server 7 standards. The DTD file name has to be changed to sun-web.xml. For more details, see http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-0.dtd.
Once the web.xml and ias-web.xml are migrated in the above-mentioned fashion, the Web application (.WAR archive) can be deployed from the Sun ONE Application Server 7’s GUI interface of the admin server or from the command line utility asadmin, where the deployment command should mention the type of application as web.
The command line utility asadmin can be invoked by running asadmin.bat file kept at Sun ONE Application Server 7 installation’s bin directory.
The command at asadmin prompt would be:
asadmin> deploy -u username -w password -H hostname -p adminport --type web [--contextroot contextroot] [--force=true] [--name component-name] [--upload=true] [--instance instancename] filepath
Deployment can also be done from the Sun ONE Studio development environment as explained in section "Deploying an Application in Sun ONE Application Server 7".
Particular setbacks when migrating servlets and JSPs
The actual migration of the components of a Servlet / JSP application from Sun ONE Application Server 6.0/6.5 to Sun ONE Application Server 7 will not require any modifications to be made to the component code.
In case if the web-application is using a server resource, for example, a DataSource, then Sun ONE Application Server 7 requires that this resource be declared inside the web.xml and correspondingly inside sun-web.xml. For declaring a DataSource called jdbc/iBank, the <resource-ref> tag as declared inside the web.xml would look like this:
<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>
Corresponding declaration inside the sun-web.xml will look 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 Enterprise EJB ModulesSun ONE Application Server 6.0 and 6.5 support the EJB 1.1 API whereas Sun ONE Application Server 7 supports the EJB 2.0 API. Thereby, both can support:
EJB 2.0 API however, introduces a new type of enterprise bean, called a message-driven bean in addition to the session and entity beans.
J2EE 1.3 specification dictates that the different components of an EJB must be grouped together in a JAR file with the following structure:
Sun ONE application servers observe this archive structure. However, the EJB 1.1 specification leaves each EJB container vendor to implement certain aspects as they see fit:
As we might expect, Sun ONE Application Server 6.0 or 6.5 and Sun ONE Application Server 7 diverge on certain points, which means that when migrating an application certain aspects require particular attention. Some XML files have to be modified:
- The <!DOCTYPE definition should be modified to point to the latest DTD url in case of J2EE standard DDs, like ejb-jar.xml.
- Replace ias-ejb-jar.xml with the modified version of this file, i.e., sun-ejb-jar.xml, which is created manually according to the DTDs. For more information, see http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-0.dtd.
- Replace all the <ejb-name>-ias-cmp.xml files with one sun-cmp-mappings.xml file, which is created manually. For more information, see http://www.sun.com/software/sunone/appserver/dtds/sun-cmp_mapping_1_0.dtd.
- Only for CMP entity beans: Generate dbschema by using the capture-schema utility in the Sun ONE Application Server 7 installation’s bin directory and place it above META-INF folder for the Entity beans.
Migrating Enterprise ApplicationsAccording to the J2EE specifications, an enterprise application is an EAR file, which must have the following structure:
In the application deployment descriptor, we define the modules that make up the enterprise application, and the Web application's context root.
Sun ONE Application server 6.0/6.5 and 7 primarily supports 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, extension .jar) for EJBs and web archives (WAR, extension .war) for servlets and JSPs.
It is therefore essential to follow the steps listed here before deploying an enterprise application:
- Package EJBs in one or more EJB modules,
- Package the components of the Web application in a Web module,
- Assemble the EJB modules and Web modules in an enterprise application module
- Define the name of the enterprise application's root context, which will determine the URL for accessing the application.
Note: Sun ONE Application Server 7 uses a new class loader hierarchy as compared to Sun ONE Application Server 6.0/6.5. 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. Hence all classes loaded by the JAR class loader are available/ accessible to the WAR module but the reverse is not true. Hence, suppose there is a certain class which is required by the JAR as well as the WAR, then it should be packaged inside the JAR module only. If this guideline is not followed it would lead to class conflicts.
Application Root Context and Access URL
There is one particular difference between Sun ONE Application Server 6.0/6.5 and Sun ONE Application Server 7, 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, then the access URL for this application will differ depending on the application server used:
- With Sun ONE Application Server 6.0 or 6.5, which is always used jointly with a Web front-end, the access URL for the application will take the following form (assuming the Web server is configured on the standard HTTP port, 80):
http://hostname/NASApp/AppName/
- With Sun ONE Application Server 7, the URL will take the form:
http://hostname:port/AppName/
The TCP port used as default by Sun ONE Application Server 7 is port 80.
Although the difference in access URLs between Sun ONE Application Server 6.0/6.5 and Sun ONE Application Server 7 may appear minor, it can however be problematical when migrating applications that make use of absolute URL references. In such cases, it will be 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 Sun ONE Application Server 6.0/6.5.
Migrating Proprietary ExtensionsA number of classes proprietary to the Sun ONE Application Server 6.0/ 6.5 environment may have been used in applications. Some of the proprietary Sun ONE packages used by Sun ONE Application Server 6.x are listed below:
These APIs are not supported in Sun ONE Application Server 7. Applications using any classes belonging to the above package will have to be re written such that the applications use standard J2EE APIs. Applications using Custom JSP tags and UIF framework also needs to be rewritten to use standard J2EE API.
For a sample migration walkthrough using the iBank application, see Chapter 5, "Migrating iBank Application - Walkthrough."
Migrating UIFSun ONE Application Server 7.0 EE does not support the use of Unified Integration Framework (UIF) API for applications. Instead, it supports the use of J2EE Connector Adapter (JCA) for integrating the applications. However, the applications developed in Sun ONE Application Server 6.5 uses the UIF. In order to deploy such applications to Sun ONE Application Server 7.0 EE, you need to migrate the UIF to JCA. This section discusses the pre-requisites and steps to migrate the applications using UIF to Sun ONE Application Server 7.0 EE.
Before migrating the applications, you need to make sure that the UIF is installed on Sun ONE Application Server 6.5. To check for the installation, you can follow any of the following two approaches:
Approach 1: Checking in the registry files
UIF is installed as a set of application server extensions. They are registered in app server registry during the installation. Search for the following strings in the registry to check whether UIF is installed.
Extension Name Set:
The registry file on Solaris Operating Environment can be found at the following location:
AS_HOME/AS/registry/reg.dat
Approach 2: Checking for UIF binaries in installation directories
UIF installers copy specific binary files in to the application server installation. A successful find of these files below indicate that UIF is installed.
The location of the following files on Solaris and Windows is: AS_HOME/AS/APPS/bin
List of files to be searched on Solaris:
List of files to be searched on Windows:
Before migrating the UIF to Sun ONE Application Server 7 EE, make sure that the UIF API is being used in applications. To verify its usage:
Migration Process
To migrate the UIF, you can use the Sun ONE Connector Builder tool. This tool is also integrated into Sun ONE Studio and hence you can use Sun ONE Studio to migrate the UIF based applications to JCA based applications. The key features of the Sun ONE Connector Builder Tool are:
Note: Migration of applications using the UIF in Sun ONE App Sever 6.5 does not require any changes in the code.
For more information on using the Sun ONE Connector Builder tool, visit the following URL:
http://docs.sun.com/db/coll/s1.conbldr
Migrating Rich Clients
This section describes the steps for migrating RMI/IIOP and ACC clients developed is Planet Application Server 6.x to Sun ONE Application Server 7 EE.
Authenticating a Client in 6.x
iPlanet Application Server provides a client-side callback mechanism that enables applications to collect authentication data from the user such as the username and the password.The authentication data collected by the iPlanet CORBA infrastructure is propagated to the Application Server via IIOP.
If ORBIX 2000 is the ORB used for RMI/IIOP, portable interceptors implement security by providing hooks, or interception points, which define stages within the request and reply sequence.
Authenticating a Client in 7 SE/EE
The authentication is done based on JAAS (Java Authorization and Authentication System API) and the client can that implement a CallBackHandler. If a client does not provide a CallbackHandler, then the Default CallbackHandler called the LoginModule will be used by the ACC for obtaining the authentication data.
For detailed instructions on using JAAS for authentication, see the Sun ONE Application Server 7 Developer’s Guide to Clients.
Using ACC in 6.x and 7 EE
In 6.x, no separate appclient script is provided. You are required to place the iasacc.jar file in the classpath instead of the iascleint.jar file. The only benefit of using the ACC for packaging application clients in 6.x is that the JNDI names specified in the client application are indirectly mapped to the absolute JNDI names of the EJBs.
In case of 6.x applications, a stand-alone client would use the absolute name of the EJB in the JNDI lookup. That is, outside an ACC, the following approach would be used to lookup the JNDI:
initial.lookup(“ejb/ejb-name”);
initial.lookup(“ejb/module-name/ejb-name”);If your application was developed using 6.5 SP3, you would have used the prefix “java:comp/env/ejb/” when performing lookups via absolute references.
initial.lookup(“java:comp/env/ejb/ejb-name”);
In Sun ONE Application Server 7, the JNDI lookup is done on the jndi-name of the EJB. The absolute name of the ejb must not be used. Also, the prefix, java:comp/env/ejb is not supported in Version 7. Replace the following jar files in the classpath with appserv-ext.jar:
iasclient.jar, iasacc.jar, or javax.jar
If your application provides load balancing capabilities, in 7, load balancing capabilities are supported only in the form of S1ASCTXFactory as the context factory on the client side and then specifying the alternate hosts and ports in the cluster by setting the com.sun.appserv.iiop.loadbalancingpolicy system property as follows:
com.sun.appserv.iiop.loadbalancingpolicy=roundrobin,host1:port1,host2:port2,...,
This property provides you with a list of host:port combinations to round robin the ORBs. These host names may also map to multiple IP addresses. If you use this property along with org.omg.CORBA.ORBInitialHost and org.omg.CORBA.ORBInitialPort as system properties, the round robin algorithm will round robin across all the values provided. If, however, you provide a host name and port number in your code, in the environment object, that value will override any such system property settings.
The Provider URL to which the client gets connected in 6.5 is the IIOP host and port of the CORBA Executive Engine (CXS Engine). In case of App Server 7, the client needs to specify the IIOP listener Host and Port number of the instance. No separate CXS engine exists in application server 7.
The default IIOP port is 3700 in App Server 7; the actual value of the IIOP Port can be found in the server.xml configuration file.
