+

Search Tips   |   Advanced Search

Change the portal URI


Overview

Gotcha

When we specify the context root, do not specify a value that is the same as a directory existing in a portlet WAR directory.

For example, if set the WebSphere Portal context root as...

...and there is also a portlet with the directory structure...

...this could cause a conflict if the portlet encodes URI references to resources in its own /images directory. In this situation, the portlet would be unable to display images because WebSphere Portal would look for the image resources according to its own context root path instead of the directory path specified by the portlet WAR file.


Change the URI of a WSRP Producer portal

Changing the WSRP Producer context root does not require redeploying all portlets. You only need to run the task...

With WebSphere Portal v8, the URI of the context root for the WSRP Producer is...

Prior to v8, this context root is...

If you migrated to portal v8 from an earlier version, you still might have WSRP Consumers that attempt to access the WSRP Producer with the previous context root (/wsrp). We can correct this issue in one of the following ways:


Change portal URI after migration from v6.1

If you migrated the portal from v6.1 to v8, the migration places the MigratedThemes application under the original context root, for example /wps.

Before we can change the portal URI to a path containing your original context root path, change the path for the migrated themes. Do this for all occurrences of the path in themes, including the EAR file for the migrated themes MigratedThemes.ear and, for example, possible hard coded occurrences in the custom theme application code. For details about how to change the path for the migrated themes, see Portal V6.1.x on application server V6.1:

Update themes and skins to remove hardcoded context root references.


WCM Syndication, the Syndicators and Subscribers

WCM syndication syndicator and subscriber servers referring to the Portal instance must be updated with the modified URI.

Log on to the WebSphere Portal syndicating to this instance. Go to...

Update the URL with the new context root information. Then log on to the WebSphere Portal subscribing to this instance. Go to...

Update the URL with the new context root information.


Change the Portal URI

If you modify the URI in a clustered environment, complete these steps on the primary node only, except where specified differently.

  1. If you changed the context root during installation on the panel...

      Configuration for IBM WebSphere Portal: Profile configuration details: Advanced

    ...proceed to step 2. Otherwise...

    1. Stop the WebSphere_Portal server.

    2. Create backups of wkplc.properties and wkplc_comp.properties

    3. Edit wkplc.properties and set the WpsContextRoot property.

    4. Save and close the file.

    5. Edit wkplc_comp.properties and enter the appropriate value for the environment in the following properties:

      • WsrpContextRoot
      • WpsPersonalizedHome
      • WpsDefaultHome

      Do not enter the same value for WpsPersonalizedHome and WpsDefaultHome.

    6. Save and close the file.

    7. Start the WebSphere_Portal server in a stand-alone environment or the dmgr and node agent in a clustered environment.

    8. Change the portal URI:

        cd WP_PROFILE/ConfigEngine
        ./ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=foo -DWasPassword=foo

      Check the output for any error messages before proceeding with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.

    9. Restart the WebSphere_Portal server.

  2. Modify context root for the portlets:

      ./ConfigEngine.sh modify-servlet-path-portlets -DPortalAdminPwd=foo -DWasPassword=foo

    Check the output for any error messages before proceeding with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.

  3. Start the WebSphere_Portal server

  4. If we are using an external Web server, such as an HTTP Server:

    1. Update the web server definition...

      • Standalone

        1. Copy the following script from the plugin_root/bin directory to the WP_PROFILE/bin directory on the WebSphere Portal server:

            scp plugin_root/bin/configurewebservername.sh portal_host:WP_PROFILE/bin

          ...where webservername is the web server definition name defined previously when configuring the HTTP Server for WebSphere Portal, for example:

            configurewebserver1.sh

        2. Update the web server definition...

            cd WP_PROFILE/bin
            ./configurewebservername.sh

      • Clustered

        1. Copy the script from the plugin_root/bin directory to the directory on the dmgr server:

            scp plugin_root/bin/configurewebservername.sh dmgr_host:dmgr_profile/bin

          ...where webservername is the web server definition name defined previously when configuring the HTTP Server for WebSphere Portal, for example: configurewebserver1.bat.

        2. Execute the following command on the dmgr server:

            cd dmgr_profile/bin
            ./configurewebservername.sh

    2. Regenerate the Web server plug-in in WAS. If we are using a remote Web server, copy the generated plugin-cfg.xml file to the remote server.

      These steps should not be completed if we are only changing the WSRP Producer URI.

    3. Restart the Web server.

    4. Restart the WebSphere_Portal server.

  5. Update the registered Application URI entries in the table...

      JCR.ICMSTJCRNODEREGISTER

    In a clustered environment, complete these steps on the primary node only.

    1. Stop the WebSphere_Portal server.

    2. Backup the database.

    3. Start the WebSphere_Portal server.

    4. Deregister the nodetypes:

      Edit...

        ./PortalServer/wcm/prereq.wcm/config/nodetypes/ibmcontentwcm.registernodetypes

      ...and change...

        <registerAction action="register"/>

      ...to...

        <registerAction action="deregister"/>

    5. Update <ApplicationURI name="wps/mypoc/?view=auth&uri=wcm:oid:"/>

      For example: 

      <registerNodeTypeDefinition name="ibmcontentwcm:classificationData">
  <registerAction action="deregister"/>
  <Application name="wcm"/>
  <ApplicationURI name="wps8/mypoc/?view=auth&uri=wcm:oid:"/>
</registerNodeTypeDefinition>

      ...and then run....

        ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=foo -DPortalAdminPwd=foo

    6. Register the nodetypes:

      Edit...

        /WebSphere/PortalServer/wcm/prereq.wcm/config/nodetypes/ibmcontentwcm.registernodetypes

      ...and change...

        <registerAction action="deregister"/>

      ...to...

        <registerAction action="register"/>

    7. Update <ApplicationURI name="wps/mypoc/?view=auth&uri=wcm:oid:"/>

      For example: 

      <registerNodeTypeDefinition name="ibmcontentwcm:classificationData">
  <registerAction action="register"/>
  <Application name="wcm"/>
  <ApplicationURI name="wps8/mypoc/?view=auth&uri=wcm:oid:"/>
  </registerNodeTypeDefinition>

      ...then run...

        ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=foo -DPortalAdminPwd=foo

    8. Run the following SQL query to verify the entries in the table now show the new URI: 
      select * from JCR.ICMSTJCRNODEREGISTER

    9. Restart the WebSphere_Portal server.

  6. If using IBM WCM, change the JSP components located in the Web Resources v70 Library:

    If a clustered environment, complete these steps on the primary node only.

    1. Log on to WebSphere Portal and go to...

        Applications | Content | Web Content Management | Preferences | Edit Shared Settings | Library Selection

      ...and add Web Resources v70 to the Selected Libraries list.

    2. Under Item Views, select...

        All Items | All | Components | JSP

    3. Select every JSP component from the Web Resources v70 library and then click Edit.

    4. Update the Path field for every JSP component with the new context root path.

      The JSP path includes two parts, which are separated by a semi-colon. The first part is the context path to the WCM extensions web application and then the second part is the path to the JSP. Update the path to the web application. For example the other path might be...

        /wcmextension;/jsp/html/general/UpdateItem.jsp

      If you changed the context root to mynewcontext, you would change the old path to:

        /mynewcontext/wcmextension;/jsp/html/general/UpdateItem.jsp

  7. Optional: Update the custom themes to reference the correct dojo context root.

    The default dojo context root in WebSphere Portal is...

      /wps/portal_dojo

    After running the modify-servlet-path and modify-servlet-path-portlets tasks, the dojo context root is changed to include the new value in the WpsContextRoot parameter as the prefix. For instance if the new WpsContextRoot value is myco, then the new dojo context root becomes...

      /myco/portal_dojo

    If the theme has hard coded references to...

      /wps/portal_dojo

    ...update those references to the new context root. If you migrated a custom theme, we might find that it has references to /portal_dojo without the /wps prefix. Look for these references in both the WAR file and in the WebDAV storage for the theme.

    Cluster note: In a clustered environment, complete these steps on the primary node only.

  8. If you changed the context root and you have existing search collections:

    Edit the content root is each existing search collection.

    1. Log on to WebSphere Portal as the administrator and go to...

    2. For the first content source in the list, select Edit Content Source icon

    3. Edit the URL listed in the Collect documents link from the URL with the new context root.

    4. Click Save.

    5. Edit the URL in each remaining content source and then save you changes.

    6. In the breadcrumb trail, click...

        Collections from All Services

      ...and select the next search collection to modify.

  9. To use the Web application bridge integration feature we are using Lotus Quickr Doc Picker:

    In a clustered environment, complete these steps on the primary node only.

    1. Log on to the WAS admin console and go to...

        Applications | Application Types | WebSphere enterprise applications | Quickr Document Picker | Web Module Properties | Context Root For Web Modules

    2. Change the context root to new_context_root.

    3. Click OK.

    4. Click Save to save the changes to the master configuration.

    5. Log out of the WAS admin console.

    6. Update the context root information in the following files to match the new context root:

      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/METAINF/application.xml
      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/WEBINF/jsp/js/config.jsp
      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/picker-packaged.js
      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/picker-packaged.js.uncompressed.js
      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/widgets/DocumentPicker.js
      • WP_PROFILE/installedApps/node_name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/widgets/PickerDialog.js
      • WP_PROFILE/installedApps/node_name/EphoxEditLive.ear/editoreditlive.war/jsp/html/EditLiveJavaEditor.jsp
      • WP_PROFILE/installedApps/node_name/PA_WCM_Authoring_UI.ear/ilwwcmauthoring.war/jsp/html/OdcEditor.jsp

  10. Resynchronize nodes and restart the cluster.

    • static cluster:

      1. Synchronize...

          System Administration | Nodes | primary node | Full Resynchronize

      2. Stop the cluster...

            Servers | Clusters | cluster | Stop

        • After the cluster has stopped, restart it by selecting the cluster and clicking Start.

    • Dynamic cluster

      1. Synchronize...

          System Administration | Nodes | primary node | Full Resynchronize

      2. Stop the cluster...

          Servers | Dynamic Clusters | dynamic cluster | cluster | Stop

      3. Select the member name to start and then click the Start button.

  11. On each node within the cluster, create WebSphere environment variables for WCM...

    1. Locate the wkplc.properties and wkplc_comp.properties files on the additional nodes in...

        WP_PROFILE/ConfigEngine/properties

      ...and create backup copies before changing any values.

    2. Edit wkplc.properties and enter the appropriate value for the environment in the WpsContextRoot property.

    3. Save and close the file.

    4. Edit wkplc_comp.properties and enter the appropriate value for the environment in the following properties:

      • WsrpContextRoot
      • WpsPersonalizedHome
      • WpsDefaultHome

      Do not enter the same value for WpsPersonalizedHome and WpsDefaultHome.

    5. Save and close the file.

    6. Create the WebSphere environment variables for WCM:

        ./ConfigEngine.sh create-wcm-servletpath-variables -DServerName=your_application_server -DWasPassword=foo

      Check the output for any error messages before proceeding with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.

  12. Resynchronize the nodes and restart the cluster.


Parent: Configuring
Related: Portal V6.1.x on application server V6.1: Update themes and skins to remove hardcoded context root references