Before you begin
The installation wizard automatically configures IBM WebSphere Application Server, Version 5.x and all other bundled products. There is no need for additional configuration if you do not migrate from an earlier version.Why and when to perform this task
If you use the installation wizard to migrate a previous installation of WebSphere Application Server, Version 3.5.x, there are some items to review before considering your environment fully configured.
Steps for this task
Note: No redeployment is required when moving EJB 1.1 JAR files from Version 4.
The J2EE programming model specifies an architecture for how applications are created and deployed. The WASPostUpgrade tool recreates applications because Version 3.5.x applications do not have the same architecture as Version 5.x applications. The Version 5.x J2EE applications contain all migrated Web resources and enterprise beans. All Version 3.5.x enterprise applications become Version 5.x J2EE applications with the same name, deployed in the same server.
The WASPostUpgrade tool maps Web resources and enterprise beans that are not included in an enterprise application, into a default J2EE application that includes the name of the server. The tool maps Web applications to J2EE WAR files. The tool deploys enterprise beans as EJB 1.1 beans in J2EE JAR files. The tool combines resources in a J2EE EAR file and deploys it in the Version 5.x configuration. There are some differences between the EJB 1.0 and EJB 1.1 Specifications, but in most cases, EJB 1.0 beans can run successfully as EJB 1.1 beans.
Version 3.5.x supports only the EJB 1.0 components specification level. Version 5.x supports EJB 1.1 components. However, many EJB 1.0 beans can successfully deploy as EJB 1.1 beans. The migration tools redeploy enterprise beans automatically as part of the application migration phase.
Note: After federating an Application Server node into a deployment manager cell, you cannot use the migration tools on the Application Server node. To use these tools again, remove the node from the cell, use the tools, and add the node to the cell again.
The WASPostUpgrade tool migrates applicable security settings in the Version 3.5.x environment to J2EE security attributes.
Global security that uses Lightweight Third Party Authentication (LTPA) authentication in Versions 3.5.x and 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 Versions 3.5.x and 4.0.x, it is disabled during migration to Version 5.x.
If you add this node later to an IBM WebSphere Application Server Network Deployment, Version 5.x configuration, you can enable and use the LTPA configuration. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, you can enable global security.
Global security that uses localos authentication mechanisms in versions 3.5.x and 4.0.x is migrated to the Network Deployment product. However, although global security was enabled in Versions 3.5.x and 4.0.x, it is disabled during migration to Version 5.x. The Network Deployment product does not support the SWAM authentication mechanism. Migration sets the authentication mechanism in Version 5.x to LTPA. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, you can enable global security.
Version 5.x does not support JSP 0.91 objects. The migration tools do not migrate JSP objects configured to run as JSP 0.91 objects. The migration tools do, however, recognize the objects in the output and log them. Version 5.x runs JSP 1.0 and 1.1 objects as JSP 1.2 objects, which is its only supported level.
Version 3.5.x models and clones and Version 4.0.x server groups have been dramatically redefined in Version 5.x as clusters and cluster members. Application servers are the only objects supported as models and cluster members in Version 5.x. This change is a significant difference from Version 3.5.x, in which many objects are models and clones. All models and clones relating to Application Servers are mapped to cluster members in Version 5.x.
During the migration of all other objects that you could previously clone, special mapping occurs. All clones are treated as simple objects and are mapped as if they are not cluster members. Models that are not Application Server models are ignored and not mapped.
Version 4.0.x Server Groups are converted to Version 5.x clusters.
A Version 3.5.x and a Version 4.0.x repository can contain more than one node name and its associated children. The WASPostUpgrade tool processes only those objects and children that match the migrating node. This determination is made by checking the names of nodes in configuration files with fully qualified and non-qualified network names of the migrating machine.
In many cases, IBM provides additional features and customization options that extend the specification level even further. If your existing Version 3.x applications use IBM extensions from earlier product versions, you might need to perform mandatory or optional migration to use the same kinds of extensions in the Version 5.x.
Migration from Version 4.0.x requires little conversion.
J2EE applications might exist on the client, if the client has client JAR files with J2EE resources.
JAXP defines a pluggability mechanism for a SAX and DOM parser via javax.xml.parsers APIs. Transformers are pluggable via javax.xml.transform APIs.
The IBM SDK 1.3.1 bundles in Version 5.0.x include an XML4J 4.0.6 parser and an XSLT4J 2.5.4 transformer. To use a different implementation of JAXP in an application, package the parser and transformer in the application and change the class loader delegation to PARENT_LAST on the application or Web module.
It is recommended that applications do not use the parser or transformer implementation API directly, but that the applications use the JAXP API.
You can change an application to remove its dependency on the API in a previous version of the parser or the transformer from an earlier version of WebSphere Application Server. Package the JAR files in the application and set the classloader delegation mode to PARENT_LAST.
You must only recompile a Version 4.0.x XML application to migrate it to the Version 5.0.x level.
Version 5.1 applications use the XML4J 4.2.2 parser and the XSLT4J 2.5.4 transformer, as described in XML parser for Java code.
If you have used a smaller heap size in the past, you can use the default heap size, which is now 50.
Results
Now you are finished with pre-test configuration. You might have to fine tune your WebSphere Application Server environment as you test it. Test all redeployed applications before moving them into production.What to do next
Return to Installing WebSphere Application Server products to continue.