7.0 version of Web Server, its easy..
you using 6.0 or 6.1
version of Web Server? Do you wanna try the new and
cool features of Sun Java System Web Server 7 with the settings of your
6.0 or 6.1
version?, then use the migration option provided in Sun Java
Web Server 7 (Download).
What will be
migrated from 6.0/6.1 to 7.0?
How to migrate?
instance of 6.0/6.1, a new configuration will be created in webserver
7.0 (Please refer to migration logs <default location is
admin-server/logs/MIGRATION\*.log> for more information on the
that will be/will not be migrated).
- Search collections can be
Web-app entries in server.xml
will be migrated. If the web-apps directory resides under config-root
of the migrating instance, it will be copied to the config-root of the
can use either GUI or
CLI to migrate.
Migrate Configuration link from the Common Tasks page to open a
wizard, which will guide you through the migration process.
CLI: Connect to wadm as
shown below. (Note
: wadm is located under the bin directory of your web server 7.0
Please enter admin-user-password>
Sun Java System Web Server 7.0-Technology-Preview-1 B05/15/2006
[--no-prompt] [--verbose] [--search-collection-copy-path=directory]
[--log-dir=directory] ( [--all] | [--config=newconfigname]
[--instance=instancename] ) --server-root=path
CLI014 server-root is a required option.
all instances of
a given 6.x installation using a single command.
--log-dir=/logDir --all=true --server-root=/Sun/WebServer6.1
of a given 6.x installation using a single command.
--log-dir=/logDir --config=rakesh --instance=https-rakesh
migrate-server --log-dir=/logDir --instance=https-rakesh
is the new
configuration name and --instance is the 6.x instance that you want
to migrate. If you do not specify the --config option, a new config
will be created from the instance name with 'https-' stripped from it
(rakesh in this case).
(1) If the
search collection path is outside the 6.x instance, then migrated
collection path will point to the same directory.
(a) If the search collection path
is within the 6.x instance, and the user enters a valid value for
search-collection-copy-path option, then the migrated collection path
name>/<vs id>/<collection name>
and migration will copy the collection to that directory.
(2) (b) If the search collection path
is within the 6.x instance, and the user enters a wrong value for
search-collection-copy-path option, then no collection will be created
and a log message will be recorded.
(3) If the search
collection path is within the 6.x instance, and the user
does not enter any value for search-collection-copy-path option, then
the migrated collection path will be
About Migration Logs
../collections/<vs id>/<collection name>
and log message will be recorded(asking the user to add the documents
manually). Admin will create the "../collections/<vs id>/<collection name>"
You can specify the
directory in which you want the
migration logs to
present.Otherwise, the default directory will be used which is,
would simply create new configurations on webserver 7.0. User has to
manually create instances for these configurations by using Create
Migration of an
instance, say "https-rakesh" from 6.0/6.1 would create a
new configuration "rakesh" on 7.0. When the user creates
an instance for "rakesh", it would be https-rakesh on web server 7.
Once you are done with
Migrating your 6.x instance(s) please refer to the migration logs for
some manual changes that you need to do.
operating system users!, you have to take care of certain things
while migrating from 6.x to 7.0. Please, refer to the "Resolving Service ID
conflicts during migration on Windows Platform"
section, to avoid service id conflicts as shown below.
create-instance --config=rakesh shogan
Node "shogan": ADMIN3210: Could
not create the instance because the
Windows service 'https-rakesh' already exists.
conflicts during migration on Windows Platform
start from migrating a 6.x instance, say "https-rakesh".
Migration using GUI would default the new configuration name to
"rakesh", ie. it strips off 'https-'.On Windows platform,
creation of instance for any config ("rakesh")
will try to register a service-id ("https-rakesh") with Windows
Services. But, the service id "https-rakesh"
is already taken by the existing 6.x instance, which is
(plese, don't get confused by "https-rakesh" being used at
two places, first one refers to service-id and the second one refers to
instance). Hence, there would be a service-id conflict and creation
of instance would fail for the migrated config.
There are two ways to
handle this scenario. The first one can be used while migrating,
whereas the second one can be used after migration.
1). Change the config name at
the time of migration. Ensure you pick a name for which the service ID
will be available.
CLI: use the –config option of the
GUI: rename the default config name in the
2).If you've forgotten to
change the config name or used --all option of while migrating, then
creation of instances would fail. As a workaround copy the configuration using
the copy-config feature of web sever 7.0
to copy this
configuration(rakesh) to a different and unique configuration(say
rakesh-6x) and make sure that the service-id https-rakesh-6x is not taken
copy-config --config=rakesh rakesh6x
CLI201 Command 'copy-config'
GUI: Go to Configurations page, click on 'copy' of
Configurations table, enter
a new config name and
the copying of configuration.
Feel free to shoot any questions on
migration or related topics.