Various configurations are mapped during migration.
Migration involves the copying of your configuration from a previous release of a WebSphere Application Server product into a new release.
Many migration scenarios are possible. The Version 6.0.x migration tools map objects and attributes to the Version 6.0.x environment when you restore a configuration from a previous version.
Migration maps a default bootstrap NameServer port setting, 900, from Version 5.x to the Version 6.0.x NameServer default, 2809. The migration tools map a non-default value directly into the Version 6.0.x environment.
The migration tools convert appropriate command-line parameters to Java virtual machine (JVM) settings in the server process definition. Most settings are mapped directly. Some settings, such as memory heap sizes, are not migrated because their roles in the Version 6.0.x configuration either do not exist, have different meanings, or have different scopes.
You can migrate a Version 5.x node that belongs to a cell without removing the node from the cell.
Migrate the deployment manager first, before migrating any base nodes in the cell.
Use the same cell name when migrating Network Deployment from Version 5.x to Version 6.0.x. If you use a different cell name, federated nodes cannot successfully migrate to the Network Deployment Version 6.0.x cell.
Migrating a base WebSphere Application Server node that is within a cell to Version 6.0.x also migrates the node agent to Version 6.0.x. A cell can have some Version 6.0.x nodes and other nodes that are at Version 5.x levels.
Migration copies files from prior version directories into the Version 6.0.x configuration. See the following section for more information.
RARs that are referenced by J2C resources are migrated if those RARs are in the old WebSphere Application Server installation. In this case, the RARs are copied over to the corresponding location in the new WebSphere Application Server installation. Relational Resource Adapter RARs will not be migrated.
During the migration of the deployment manager Version 5.x samples for federated nodes are migrated. Equivalent Version 6.0.x samples are available to use for all other Version 5.x samples.
The package that contains the DefaultErrorReporter servlet changed as of Version 5. In Version 6.0.x, the servlet is in the com.ibm.ws.webcontainer.servlet class. Direct use of the DefaultErrorReporter servlet has been deprecated.
<?xml version="1.0" encoding="UTF-8"?> <webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi" xmlns:commonext.localtran="commonext.localtran.xmi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmi:id="WebApp_ID_Ext" reloadInterval="3" reloadingEnabled="true" fileServingEnabled="false" directoryBrowsingEnabled="false" serveServletsByClassnameEnabled="true" preCompileJSPs="false" autoRequestEncoding="false" autoResponseEncoding="false"> <defaultErrorPage xsi:nil="true"/> <additionalClassPath xsi:nil="true"/> <webApp href="WEB-INF/web.xml#WebApp_ID"/> <extendedServlets xmi:id="ServletExtension_1"> <extendedServlet href="WEB-INF/web.xml#Servlet_1"/> </extendedServlets> <extendedServlets xmi:id="ServletExtension_2"> <markupLanguages xmi:id="MarkupLanguage_1" name="HTML" mimeType="text/html" errorPage="Page_1" defaultPage="Page_2"> <pages xmi:id="Page_2" name="Hello.page" uri="/HelloHTML.jsp"/> <pages xmi:id="Page_1" name="Error.page" uri="/HelloHTMLError.jsp"/> </markupLanguages> <markupLanguages xmi:id="MarkupLanguage_2" name="VXML" mimeType="text/x-vxml" errorPage="Page_3" defaultPage="Page_4"> <pages xmi:id="Page_4" name="Hello.page" uri="/HelloVXML.jsp"/> <pages xmi:id="Page_3" name="Error.page" uri="/HelloVXMLError.jsp"/> </markupLanguages> <markupLanguages xmi:id="MarkupLanguage_3" name="WML" mimeType="vnd.wap.wml" errorPage="Page_5" defaultPage="Page_6"> <pages xmi:id="Page_6" name="Hello.page" uri="/HelloWML.jsp"/> <pages xmi:id="Page_5" name="Error.page" uri="/HelloWMLError.jsp"/> </markupLanguages> <extendedServlet href="WEB-INF/web.xml#Servlet_2"/> </extendedServlets> <extendedServlets xmi:id="ServletExtension_3"> <extendedServlet href="WEB-INF/web.xml#Servlet_3"/> <localTransaction xmi:id="LocalTransaction_1" unresolvedAction="Rollback"/> </extendedServlets> </webappext:WebAppExtension>
The location for these directories is typically within the installation directory of a previous version. The default location for stdin, stdout, and stderr is the logs directory of the Version 6.0.x installation root. The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate Version 6.0.x defaults are used.
Using common directories between versions in a coexistence scenario can cause problems.
The migration tools migrate all ports. The tools warn about port conflicts in a log when a port already exists. You must resolve port conflicts before running the servers that are in conflict, at the same time.
The specification level of the Java 2 Platform, Enterprise Edition (J2EE) that Version 6.0.x implements requires behavior changes in the Web container for setting the content type. If a default servlet writer does not set the content type, not only does the Version 6.0.x Web container no longer default to it, the Web container returns the call as "null". This situation might cause some browsers to display resulting Web container tags incorrectly. Migration sets the autoResponseEncoding IBM extension to true for Web modules as it migrates enterprise applications. This action prevents the problem.
Migrating from Version 5.x to Version 6.0.x is much less complicated than previous migrations. Both versions use the same underlying definitions. The task involves mapping configuration files from the Version 5.x to the Version 6.0.x configuration and copying installed applications into the new product. The migration tools support the migration of federated nodes and support the full migration of a Network Deployment node.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Increase the maximum Java heap size and follow the instructions below to install the application:
Installing the application on WebSphere Application Server Version 6.0.x
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\AppServer\\installableApps\\ EAR_file_name {-nodeployejb -appname app_name -server server_name -node node_name}"
Installing the application on WebSphere Application Server Network Deployment Version 6.0.x
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\DeploymentManager\\installableApps\\ EAR_file_name> {-nodeployejb -appname app_name -cluster cluster_name}"