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.