InfoCenter Home >
3: Migration overview >
3.2: Migrating from previous product versions >
3.2.2: Migrating from Version 3.x >
3.2.2.2: Migrating configurations manually >
3.2.2.2.4: Mapping configurations to Version 4.0

3.2.2.2.4: Mapping configurations to Version 4.0

This section details how objects and attributes are mapped to the Version 4.0 environment when you restore a configuration from an earlier product version.

  • Directories stdin, stdout, and stderr; passivation directory and working directory

    Because the typical location for these directories might include Version 3.x installation directories and the location might be different in the new Version 4.0 installation, additional checking is done for these entries if they are specified. Changed from Version 3.x, the default location for stdin, stdout, and stderr is the logs directory in Version 4.0 installations. Existence of the passivation and working directories is checked before the directories are mapped. If they exist, they are used; otherwise, appropriate defaults are used instead.

  • Enterprise beans

    EJB 1.0 was the only specification level supported in Version 3.x; EJB 1.1 is the only level supported in Version 4.0. However, many EJB 1.0 beans can be deployed as EJB 1.1 beans successfully. Enterprise beans are redeployed automatically as part of the application migration phase. Be sure to check WASPostUpgrade.log for details of the deployment of these beans; make required changes and redeploy.

  • JDBC providers and datasources

    JDBC and DataSource objects are significantly redefined in Version 4.0. These objects are mapped to the new configuration by using the Version 3.x settings as input variables.

    You might notice a difference between the datasources mapped from Version 3.x and those defined by the samples. The difference is in the user ID and password fields of the datasource. The samples provide a default user ID and password, but the migrated datasources do not. This is because user ID and password data is defined in enterprise-bean bindings, not in the datasource. In Version 3.x, the information is defined at the container and EJB level and so must be mapped to the enterprise bean.

  • JSP levels

    JSP 0.91 is not supported in Version 4.0. JSP objects that are configured to run as JSP 0.91 are not migrated, but they are noted in the output and logged. JSP 1.0 and 1.1 objects are run as JSP 1.1, because that is the only supported JSP level in Version 4.0.

  • Models and clones

    Models and clones have been dramatically redefined in Version 4.0. Application servers are the only objects supported as models and clones in Version 4.0. This is a significant difference from Version 3.x, in which many objects could be models and clones. All models and clones relating to application servers are mapped to server groups in Version 4.0.

    During the migration of all other objects that were previously clonable, special mapping occurs. All clones are treated as simple objects and are mapped as if they were not clones. Models that are not application server models are ignored and not mapped.

  • Multiple application servers

    In Version 4.0 Advanced Single Server and Advanced Developer editions, only one application server is configured at one time. In Version 3.x, there can be many application servers defined at one time. During migration of these objects to one of these Version 4.0 editions, the names of the application servers determine how migration occurs. If the names of the application servers match (for example, Default Server), the attributes of the Version 4.0 object are updated to match the previous configuration, and all children are migrated into that application server. If the names do not match, just the children of that Version 3.x application server are migrated to the one application server in the Version 4.0 environment.

  • Node name

    A Version 3.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 node that is being migrated. This determination is made by checking the names of nodes in the configuration files with fully qualified and nonqualified network names of the machine that is being migrated.

  • Servlet Redirector

    Servlet Redirector is not supported in Version 4.0; these objects are ignored.

  • Transports

    The default transport type of the Servlet Engine in Version 3.x was Open Servlet Engine (OSE). Because OSE transport is no longer supported in Version 4.0, these transports are mapped to HTTP transports using the same port assignments.

  • datasources.xml

    In Version 3.x, a datasources.xml file could be used to augment datasource configuration settings. This file was stored in the properties directory. If this file exists, the properties in the file are merged into the configuration of the datasource and JDBC provider configuration.

Other mapping information

In a Version 3.02.x environment, the arguments field in the Default Server object might contain a value of -mx128m. This value is not used in the Version 4.0 environment and is ignored. This value can be removed from the application server arguments field.

In Version 3.02.x, the name of the web/examples/showCfg servlet class was ServletEngineConfigDumper. In versions 3.5 and later, the class name is com.ibm.websphere.examples.ServletEngineConfigDumper. Be aware of this name change if you plan to use this class in the Version 4.0 environment.

Go to previous article: Restoring the previous configuration to the new installation Go to next article: Migrating from Version 4.0 Advanced Single Server Edition

 

 
Go to previous article: Restoring the previous configuration to the new installation Go to next article: Migrating from Version 4.0 Advanced Single Server Edition