Various configurations are mapped during migration.
Migration always involves migrating a single instance to another single instance (profile) on the same machine or a separate machine. Examples include a Version 5.x deployment manager migrating to a Version 6.0.x deployment manager profile and a Version 5.x application server migrating to a Version 6.0.x standalone application server profile.
Many migration scenarios are possible. The Version 6.0.x migration tools maps 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 4.0.x Advanced Edition or 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.
For Version 4.0.x Advanced Single Server Edition migration, the bootstrap NameServer port maps to the NameServer value of the application server defined in the server configuration file.
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.
Version 4.0.x server groups are converted to Version 6.0.x clusters. Migration configures cluster members differently than standalone servers. When migrating a server group, all servers in the group are assigned to the HTTP transport port number of the server group, regardless of whether or not they each had a unique port number. Therefore, after migration, all the application servers in the new cluster use the same HTTP transport port. You can use the administrative console to assign unique port numbers, which lets you run the server without federating it.
The name of the default server in Version 6.0.x is server1. All objects previously owned by the DefaultServer of Version 4.0.x are owned by server1 of Version 6.0.x after migration.
Migration does not deploy enterprise applications on cluster members when migrating from Version 4.0.x. You must manually deploy these applications on the cluster using scripting or the deployment manager administrative console. When migrating from Version 5.x, the applications are deployed automatically.
Version 6.0.x significantly redefines JDBC and data source objects. The migration tools map Version 4.0.x data sources to Version 6.0.x data sources, using predecessor settings as input variables.
jmsserver is changed from type MESSAGE_BROKER to type APPLICATION_SERVER. Any queues or topics that it owned have been migrated into the Version 6.0.x default messaging provider, which is based on service integration technologies. In previous releases, in a Network Deployment environment, jmsserver was its own MESSAGE_BROKER server; in the base environment it was contained within APPLICATION_SERVER types. All JMS resources are left untouched and should work without modification. Further migration of these resources can be performed by running scripts/bats provided by the Version 6.0.x default messaging provider. For more information on the JMS resources, see Learn about messaging resources .
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.
A Version 4.0.x repository can contain more than one node name and associated children. The WASPostUpgrade tool processes only those objects and children that match the node name of the migrating node. The tool identifies node names in the configuration files that it is migrating and selects any node names in a configuration file that match the long network name or short network name of the migrating machine.
The configuration of the PageList servlet has changed from Version 4.0.x. Direct use of the servlet has been deprecated. The PageList servlet is available as part of the servlet extension configuration in the Web archive (WAR) file. All references are updated to the servlet configuration supported in Version 6.0.x.
You can also use the Application Server Toolkit (AST) and Rational Web Developer to modify the servlet configuration. See Assembly tools for more information.
Error 500: No PageList information is configured for servlet EmpInfoApp.SearchByDept
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.
Java 2 Security is enabled by default in Version 6.0.x. Security enablement might cause some applications to run on Versions 4.0.x and not run on Version 6.0.x. Several techniques are available that you can use to define different levels of Java 2 Security in Version 6.0.x. One is to create a was.policy file as part of the application, to enable all security permissions. The migration tools call the wsadmin command to add an existing was.policy file in the Version 6.0.x properties directory to enterprise applications as they migrate. The migration tools perform this task while moving Version 4.0.x applications into Version 6.0.x.
Global security that uses Lightweight Third Party Authentication (LTPA) in Version 4.0.x is migrated to the base WebSphere Application Server product and to the Network Deployment product. However, although global security was enabled in Version 4.0.x, it is disabled during migration to Version 6.0.x (security is NOT disabled when migrating from Version 5.x).
The Global security feature that uses localos authentication mechanisms in Version 4.0.x is migrated to the Network Deployment product. However, although global security was enabled in Version 4.0.x, it is disabled during migration to Version 6.0.x. The Network Deployment product does not support the authentication mechanism known as SWAM. Migration sets the authentication mechanism in Version 6.0.x to LTPA. Use the administrative console to generate keys for the migrated LTPA. After generating the keys, you can enable global security.
Use the Version 6.0.x administrative console to change these settings to match your Version 4.0.x property values, if necessary.
Version 4.0.x server groups are redefined in Version 6.0.x as clusters. Application servers are the only objects supported as cluster members in Version 6.0.x.
The package that contains the DefaultErrorReporter servlet changed as of Version 5. In Version 4.0.x, the servlet is in the com.ibm.servlet.engine.webapp class. 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.
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.
No redeployment is required when moving EJB 1.1 JAR files from Version 4.0.
Specify only one back-end data store vendor per JAR file. If enterprise beans use different back-end data stores, package them into separate JAR files.
All JMS resources from Version 4.0 are mapped into generic JMS resources in the Version 6.0.x configuration. Reconfigure JMS resources that use IBM WebSphere MQ as IBM WebSphere MQ-specific resources. MQ JMS resources have better integration with system management. You do not need to manually define entries in the name space. You can see the backing MQ queue definitions through MQ JMS entries.
In Version 4.0.x, the classes generated from JSP files are in a package based on the directory structure of the WAR file. Any JSP file at the top of the context root is in the unnamed package. JSP files in subdirectories of the root are in packages named after the subdirectories. In Version 6.0.x, the classes generated from JSP files are all in the org.apache.jsp package. Therefore, the class files are not compatible between versions.
When migrating an enterprise application from Version 4.0.x to Version 6.0.x, recompile the JSP files to regenerate the class files into the correct packages.
The migration tools provide this support, by using the -preCompileJSPs option of the wsadmin command during the installation of the application.
Use the same option to install any Version 4.0.x enterprise applications that you manually move to Version 6.0.x.
You can apply security in two Version 4.0.x locations to enterprise applications. Information in the repository has precedence over information in the enterprise application bindings. The migration tools migrate information in the repository to the enterprise application.
The following SSLConfig attributes that point to user-defined key files are migrated from WebSphere Application Server Version 4.0.x (AE) or Version 5.x to Version 6.0.x as follows:
<key_file_name>dir_name/WASLDAPKeyring.jks</key_file_name> <trust_file_name>dir_name/WASLDAPKeyring.jks</trust_file_name>The dir_name variable identifies the original location of the WASLDAPKeyring.jks file.
keyFileName="dir_name/WASLDAPKeyring.jks" trustFileName="dir_name/WASLDAPKeyring.jks"The dir_name variable identifies the original location of the WASLDAPKeyring.jks file.
<key_file_name>${WAS_HOME}/keys/WASLDAPKeyring.jks</key_file_name> <trust_file_name>${WAS_HOME}/keys/WASLDAPKeyring.jks</trust_file_name>
keyFileName="${USER_INSTALL_ROOT}/keys/WASLDAPKeyring.jks" trustFileName="${USER_INSTALL_ROOT}/keys/WASLDAPKeyring.jks"
The migration tools do not copy the key files (for example, .jks, or .kdb) to the corresponding directory in the base WebSphere Application Server product or the Network Deployment product. You must complete the migration of the SSL configuration by copying qualifying key store files to Version 6.0.x directories.
If the key-file-name and trust-file-name attributes point to the DummyServerKeyFile.jks file in the WebSphere Application Server Version 4.0.x (AE) or Version 5.x configuration, the key-file-name and trust-file-name attributes are not migrated to Version 6.0.x. Instead the Version 6.0.x default value of ${USER_INSTALL_ROOT}/etc/DummyServerKeyFile.jks is left unchanged.
If the web.xml file defines the DefaultErrorReporter servlet, the migration tools update the class name to reflect the Version 6.0.x package. 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>
Migrating from Version 5.x to Version 6.0.x is much less complicated than migrating from Version 4.0.x. 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.
When migrating all Version 5.x EAR files to Version 6.0.x using the wsadmin tool, the WASPostUpgrade tool uses the default maximum Java heap size value of 64 MB to install the EAR files.
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}"