Before you begin
Utilize the migration utility that was shipped in W401502 to process V4.0.1 EARs. This utility is being provided as an option on 390fy. In V4.0.1 it was required that EARs be processed through the 390 AAT or 390fy to condition them for deployment into V4.0.1. In V5 and higher, this conditioning is not required. This utility will remove the conditioning that was done for existing V4.0.1 EARs that are being migrated to V5 or higher. It should be noted that if the application is being sent back through the WSAD 5.0 tooling, that the resulting EAR is ready for installation into V5 or higher and that the use of migration utility is not required. Support for migrating V4.0.1 applications to V5 and higher has been shipped in V4.0.1 service (W401502). This support has been provided as a new -v5mp option for the 390fy tool.The
V4 migration option on 390fy is enhanced via feature WS18354.08 which is shipped
in V4.0.1 service (W401609) to detect whether one or more methods of an EJB
have syncToOSThread specified in the extended deployment descriptor. If 390fy
finds syncToOSThread specified on any method within an EJB, it will add the
following new env-entry to the standard deployment descriptor of the output
EJB jar file for each of the EJBs that contained at least one or more synchToOSThread
methods:
<env-entry> <description>SyncToOSThread Setting</description> <env-entry-name>com.ibm.websphere.security.SyncToOSThread</env-entry-name> <env-entry-value>true</env-entry-value> <env-entry-type>java.lang.Boolean</env-entry-type> </env-entry>In WAS 4.0.1, syncToOSThread could be defined at the individual method level. With this new functionality, if any method within an EJB specifies syncToOSThread, then syncToOSThread will be defined for the entire EJB.
The following are the steps needed to migrate your V4.0.1 application to V5 and higher:
Why and when to perform this task
Steps for this task
Note: This step is optional.
Your J2EE server (for example, J2SERV1) might contain the following installed applications:
When you export the J2EE server (J2SERV1 in this example) into the <export_dir>/<server_dir> (for example, "/export_dir/J2SERV1") directory, the directory will look like the following:
/export_dir/J2SERV1/> ls -1 <UUID_for_J2SERV1>.ear <UUID_for_BVTEC>.ear <UUID_for_PolicyIVP>.ear <UUID_for_some_DataSource1>.xml <UUID_for_some_DataSource2>.xml server.xml
When you run the 390fy command in this directory it will generate a new *_v5mp.ear for each EAR file processed by the 390fy v5mp option.
Note: The last parameter of the "390fy" command for the "-v5mp" option is a directory. In this case, it is the directory of the <export_dir>/<server_name> where the *.ear has been exported. For example:
/export_dir/J2SERV1/> /usr/lpp/WebSphere/bin/390fy -v5mp .where "." is the target directory where the *.ear files can be found, or
/export_dir/J2SERV1/> /usr/lpp/WebSphere/bin/390fy -v5mp /export_dir/J2SERV1/where "/export_dir/J2SERV1/" is the target directory where the *.ear files can be found.
The following demonstrates the 390fy v5mp option for this example:
/export_dir/J2SERV1/> /usr/lpp/WebSphere/bin/390fy -v5mp . /export_dir/J2SERV1/> ls -1 <UUID_for_J2SERV1>.ear <UUID_for_BVTEC>.ear <UUID_for_PolicyIVP>.ear <UUID_for_J2SERV1>_v5mp.ear <UUID_for_BVTEC>_v5mp.ear <UUID_for_PolicyIVP>_v5mp.ear <UUID_for_some_DataSource1>.xml <UUID_for_some_DataSource2>.xml server.xml
The UUID for each application can be looked up in the server.xml file to find the original application name.