If you use the migration tools to migrate an installation of WebSphere
Application Server Version 4.0.x, there are additional steps that you might
need to take before considering your environment fully configured.
- Examine any Lightweight Third Party Authentication (LTPA) security
settings you might have used, and apply the settings in the WebSphere Application
Server security settings.
Global security that uses Lightweight Third Party Authentication
(LTPA) authentication 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.
If you add this node
later to an IBM WebSphere Application Server Network Deployment, Version 6.0.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 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 SWAM authentication mechanism.
Migration sets the authentication mechanism in Version 6.0.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.
- Check the WASPostUpgrade.log file in the logs directory,
for details about JavaServer Pages (JSP) 0.91 objects that the
migration tools do not migrate.
Version 6.0.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 6.0.x runs JSP 1.0 and 1.1 objects
as JSP 1.2 objects, which is its only supported level.
- Be aware that Version 4.0.x Server Groups
are converted to Version 6.0.x clusters.
Version 4.0.x server
groups have been dramatically redefined in Version 6.0.x as clusters and cluster
members. Application servers are the only objects supported as models and
cluster members in Version 6.0.x.
- Identify and use the migration tools to migrate non-migrated nodes
in Version 4.0.x repositories that have multiple nodes.
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.
- Update J2EE resources in client JAR files to the new resource format
with the ClientUpgrade tool.
J2EE applications
might exist on the client, if the client has client JAR files with J2EE resources.
- To migrate a Version 4.0.x or V5.x XML application to
the Version 6.0.x level, you must recompile it.
- Migrate V4.0.x applications to use the XML4J 4.0.6 parser and the
XSLT4J 2.5.4 transformer.
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.4.1 bundles in Version
6.0.x include an XML4J 4.2.2 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 6.0.x level.
Version 6.0.x applications use the XML4J 4.2.2 parser and the
XSLT4J 2.5.4 transformer.
- Configure WebSphere Application Server to use a database.
For example, you can configure
WebSphere Application Server to use DB2.
- Review your Java
virtual machine settings to verify that you are using a heap size of
at least 50 for improved startup performance.
If you have used
a smaller heap size in the past, you can use the default heap size, which
is now 50.