Oracle iPlanet Web Server 7.0.9 Release Notes

Migration and Upgrade

The following table lists the known issues in the migration and upgrade areas of Web Server.

Table 6 Known Issues in Migration and Upgrade

Problem ID 



Not all properties from 6.0 jvm12.conf file are migrated to 7.0 server.xml file

When migrating from Sun iPlanet Web Server 6.0 to Oracle iPlanet Web Server 7.0, properties in the 6.0 jvm12.conf file of the form

name = value

are not migrated as JVM options to the 7.0 server.xml file. Only the properties listed in jvm12.conf Parameter Reference in iPlanet Web Server 6.0, Enterprise Edition Programmer's Guide to Servlets ( are migrated.


Migrate these properties' values manually. To do so, use Chapter 3, Elements in server.xml, in Oracle iPlanet Web Server 7.0.9 Administrator’s Configuration File Reference to locate the server.xml element or subelement that corresponds to the jvm12.conf property you are migrating, and transfer the value to the server.xml file.


Incorrect migration occurs while migrating from Web Server 6.0 to 7.0 if the installed.pkg file is not found.

In Web Server 6.0 to 7.0 migration, if the installed.pkg file is missing, Web Server incorrectly migrates the NSServlet entries in the magnus.conf file.


6.x -> 7.0: Migrated scheduled events still points to 6.x paths in the server.xml file.



6.1->7.0: Migration does not handle relative path set for search-collection-dir correctly.

During instance migration, specifying a relative path for the target path into which the search collections should be copied, results in the search collection directory being created with respect to the config-store. When the instance is instantiated, the indexes are created without properly migrating the search collections.


6.x->7.0: Migration ignores any "document-root" NameTrans specified in the obj.conf file.


On Windows, Web Server Admin Console does not appropriately warn users during migration.

Administration Server does not detect if the selected new configuration or the service name already exists on Windows and hence does not appropriately warn the users to select a different configuration name or suggest a different configuration name as default. 


Web Server 7.0 migration tool is unable to successfully migrate from Web Server 6.1 if it has Root Certs installed in it.


The request processing behavior has changed in Web Server 7.0 Update 2 release.

This change does not manifest while using Web Server 7.0 Update 2 RPP. 

A modification in the Web Server's request processing engine to fix a significant error in Web Server, has changed the order in which the web server processes objects and directives in the server's obj.conf file. This correction now guarantees that the below rules are applied while processing a request:

  • All ppath objects that apply to a request are evaluated

  • If there is a named object that applies to a request, it will take precedence over any ppath objects in cases where the two conflict.

If your obj.conf file contain ppath objects, evaluate them to determine if your obj.conf file requires any modification. As a consequence of the above change in the request processing behavior, when you upgrade previous Web Server versions to the Web Server 7.0 Update 2, or later, you may have to make minor changes to the obj.conf files, as described after this table.

Handling the request processing behavior change in Web Server 7.0 Update 2

As a consequence of the change to the request processing behavior, when you upgrade previous Web Server versions to the Web Server 7.0 Update 2 or later, you may have to make minor changes to the obj.conf files, as listed below:

  1. Using IF directive

    In the following example, directives contained in the ppath objects will not be invoked when an explicit JSP extension is found in the request URI, as the ntrans-j2ee NameTrans SAF will apply to a JSP extension and cause the object named j2ee to be evaluated next. The WebLogic proxy service used here to forward requests to the WebLogic server is no longer invoked, although there are no modifications made to the obj.conf file. As a result, the web server sends the request to it's own web container, instead of the WebLogic proxy, resulting in failure of the request.

    In the obj.conf file, default object, add a conditional statement to the ntrans-j2ee service with the problem URIs, as shown below:

    <Object name="default">
    AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
    #Adding <IF...> and </IF> bracketing to compensate
     for change in ppath processing
    <IF $uri !~ ".*WebApp/.*" >
    NameTrans fn="ntrans-j2ee" name="j2ee"
    PathCheck fn="find-index-j2ee"
    ObjectType fn="type-j2ee"
    Error fn="error-j2ee"
    <Object name="j2ee">
    Service fn="service-j2ee" method="*"
    <Object ppath="*/examplesWebApp/*" >
    Service fn=wl_proxy WebLogicPort=7001
    <Object ppath="*/ejemploWebApp/*">
    Service fn=wl_proxy

    This allows the ntrans-j2ee to be executed only when the URI's do not match.

  2. Using assign-name NameTrans

    In simple scenarios, you can change ppath objects to name objects by using assign-name in the default object. This allows the assign-name to be executed ahead of ntrans-j2ee.

    <Object name="default">
    NameTrans fn="assign-name" from="/examplesWebApp/*" name="examples_proxy"
    NameTrans fn="assign-name" from="/ejemploWebApp/*" name="ejemplo_proxy"
    NameTrans fn="ntrans~j2ee" name="j2ee"
    <Object name="j2ee">
    Service fn="service-j2ee" method="*"
    <Object name="examples proxy" >
    Service fn=wl_proxy WebLogicPort=7001
    <Object name="ejemplo proxy">
    Service fn=wl_proxy WebLogicPort=7002
  3. Disabling

    Turning off Java Web container support on web server will ensure that the JSPs will be handled by WebLogic proxy function. However, this is only suggested when you do not intend to host Java content in the proxying tier.