Thoughts on Portal from Level 2 Support

Both caches operate independently of each other, so it is entirely possible one cache could timeout, while the other cache would still be active.

 

*Author's technical note:  The current code will reload all entries in the LDAP.  This may not be a good test case if you have a large LDAP.   You may update the following line of code similar to the following if you require a smaller testcase to begin with:  userList = pumaLocator.findUsersByAttribute("uid","travis*");

Special Note for 85x and 8001 CF13+

WebSphere Portal originally used private internal APIs to WebSphere Application Server to achieve the cache clearing functionality for the VMM AttributesCache.  Beginning in WebSphere 80x, VMM began to offer a public API for any WebSphere Application Server product to leverage.  When Portal 80x was released, it was still using the default private APIs and not the public API.

For Portal 8001x, a new APAR has been created - PI19201 - which switches over from use of the private VMM APIs to the public VMM APIs.  The APAR functionally is similar to PM16430 for cache invalidation.  However, the APAR does NOT require the manual properties store.puma_default.wim.cacheinvalidation.enabled and store.puma_default.wim.cacheinvalidation.repositoryids.  The properties were originally required for PM16430 due to private APIs in use but are no longer required for the public APIs.  If you have these properties defined and you install 8001 CF13 or later, your reload() code will continue to function, however these properties will no longer be required or used.

For Portal 85x, the public VMM APIs were built into the GA code.  Therefore, the manual properties store.puma_default.wim.cacheinvalidation.enabled and store.puma_default.wim.cacheinvalidation.repositoryids are not required for 85x if you implement the reload() functionality.

4)  Portal 8001 versions CF07-CF12 do not work with PM16430.  PUMA caches will invalidate with the reload() call, but the VMM attributescache will not invalidate leading to stale data being returned.  A newer cumulative fix with PI19201 must be installed to restore the invalidation functionality for the VMM attributescache.

Login URL overview:

Disabling the Auto-login URL

The automagic login URL may be disabled in Portal 8001 cumulative fix 12 or later, or, any version of Portal 8.5..  To do so:

i. Login to the WebSphere Administration Console
ii. Navigate to Resources > Resource Environment Providers > WP AuthenticationService > Custom Properties
iii. Create a new custom property
name: authentication.isLoginUrlActive
value: false
type: java.lang.Boolean
iv. Save changes. If clustered, sync nodes.
v. Restart the Portal server.

If you are not on one of these versions of Portal and need to block the auto-login URL, utilize a rewrite rule on your web server.

General Information on IIM:

• IBM Installation Manager replaces the ISMP installer and Portal Update Installer (PUI) and manages life cycle for WAS 8 and WP 8. IIM can install and uninstall core products, update or rollback fixpacks and fixes, modify and remove features
• IIM version 1.5.2 or higher required
• Silent install supported on all platforms. GUI mode supported ONLY on Windows/Unix platforms. Command line supported ONLY on z/OS.
• Can record a response file without actually installing the product either by manually editing a sample response file that comes with the media or record one using IIM.
• IIM is composed of a binary directory (from where you run the product) and a data directory (logs are recorded here).
• IIM cleans up everything after a failed install. Need to create a log.properties with debug lines to pause IIM on a failure. This will allow for time to collect logs.
• When viewing IIM logs for a Portal 8 install, use a browser to open the index.xml file from the IIM logs location for better formatting of the logs. You will need the log.xsl file in the same directory.
• To uninstall IIM, for GUI navigate to IM_DATA_DIR/uninstall/uninstall, for console navigate to IM_DATA_DIR/uninstall/uninstallc

General Information on WebSphere Portal 8 Installation:

• Portal 8 packaging comes from 3 sources: Live repository via Passport Advantage, physical DVD's, and electronic images.
• Can install WAS 32-bit on a 64-bit platform
• Can install to an existing WAS for any content offering. Express MUST install its own WAS.
• Using an advanced configuration, can change such options as context root, default home, profile name, etc.
• Content offerings (Enable, Extend, WCM and WCM SE) are an extended offering of WP 8 Server and cannot be installed without a WP 8 Server.
• WAS ND binary cannot be shared between multiple WP 8 Server offerings

Portal v8 Regular Offerings (Server, Enable, Extend, WCM, WCM SE)

Best Practices:

• A repository contains the required parts for installation. For Portal, one needs WAS, Portal, content offering, and Setup repositories.
• Single set of Portal binaries for each content offering (Server, Enable, Extend, WCM, etc.)
• Provide up-sell from server to WCM offering without reinstall
• Select all required iFixes for WAS 8.0.0.3 when installing Portal 8
• Extract all electronic images to the same directory.
• Setup disk is unique to each offering. It's different for Server, Enable, Extend, etc. If installing all at the same time, make sure to have the correct assembly.
• There is no tracing or logging with launchpad.
• Always choose the repository.config from the setup disk, <Setup_Disk_location>/eimage, when chosen, there are no prompts for individual disks over choosing the repository.config from individual offerings (WAS, Portal, Portal Offering).
• For iSeries ONLY, change Portal profile to 64-bit JVM SDK. Requires WAS managesdk task and ConfigEngine modify-jvm-heap-size and swith-64bit-lum-file tasks.

• May need clean up of some directories after uninstalling Portal and WAS. Should only be a remaining AppServer directory. This is expected.

 

6)   At the VERY top of the file, just under display name


 

Add the following:

 

<filter>

   <filter-name>Home Substitution Filter</filter-name>
   <filter-class>com.ibm.wps.engine.ServletSubstitutionFilter</filter-class>

</filter>

 

Resulting in:

Add the following between these two lines:
<filter-mapping>
   <filter-name>Home Substitution Filter</filter-name>
   <url-pattern>/portal/*</url-pattern>
</filter-mapping>


resulting in:

 

9)  Portal v8 only:  Open the /tmp/wps_expanded/wps.war/WEB-INF/web_merged.xml file in a text editor.  Repeat steps 6-8 in this file. 

14b)  Portal v8 only:  Verify the web_merged.xml also contains the changes.

Addendum to Original Posting

New bits of information will periodically be added to this entry. 

1)  Portal Infocenters

The official source of information should be the Portal Infocenters, with blog entries (such as this one) providing supplemental information to the Infocenters.

v61 Infocenter:

- Exporting the wps.ear file:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/admin/wsrpt_secltpa_expear1.html

- Redeploying the wps.ear file:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/admin/wsrpt_secltpa_redeploy.html

v70 Infocenter:

- Exporting the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Exporting_the_portal_EAR_file_wp7

- Redeploying the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Redeploying_the_portal_EAR_file_wp7

v80 Infocenter: 

- Exporting the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Exporting_the_portal_EAR_file_wp8

- Redeploying the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Redeploying_the_portal_EAR_file_wp8

2)  Portal v8 web_merged.xml file:

The original article was targeted towards WebSphere Portal 6.1 primarily.  Additional actions are required for WebSphere Portal 8.0.  In particular, both the web.xml and web_merged.xml file for wps.ear must be updated for changes to go into effect.  (Thanks Thomas for the tip!)

Introduction

One of the questions we often receive is a fairly simple question - "How many users are logged into Portal right now?".  Most of the time, the response is not a straightforward answer, but a series of counter-questions which ask "What do we define as the user being logged in?"

- If a user clicks logout, that can be considered a straightforward answer of "they are no longer logged in, therefore, do not count them".
- If a user perform a login to Portal with Firefox, then perform a login to Portal with Chrome, do we consider that one login, or two logins?
- If a user closes their web browser, but doesn't logout from Portal, do we still consider them logged in, or, are they logged out?
- If a user steps away from their machine for a brief period of time, and comes back, the session timeout has tripped but the LTPA timeout has not tripped - do we consider them logged in or logged out at that point?
- If a user adds an item to a shopping cart, but is not yet logged into the Portal site, do we consider that as being "logged in?"


And this is the tip of the iceberg without going into the multitude of additional configuration options available in WAS/Portal which could spawn many many more questions.  For purposes of this blog entry - we will define the number of logged in users to Portal to be roughly equivalent to the sessions that exist in the Portal.  For Portal sites which require a login to the Portal, this will provide a fairly accurate count of users active in the Portal server.  For Portal sites which do not require a login, but do have public session enabled, the same logic holds - it is a good approximation of how many users are active on the Portal server.  For Portal sites which do not require a login and do not require a public session, this blog entry will unfortunately not apply to those sites and a different set of tools are needed to make determination for such sites.   For the Portal sites which do require a session - we will answer that question in this blog entry.

Setting up Monitoring

WebSphere Application Server ships a built-in set of monitoring code called Performance Monitoring Infrastructure (PMI).  PMI can be used to monitor a number of different activities in a WAS server - such as the total number of database connections, total number of LDAP connections and for what we are interested in discussing - the total number of active sessions in a Portal server.  PMI itself is enable on a per application basis and for WebSphere Portal there are typically over a hundred applications deployed to a Portal server.  Enabling PMI across all applications would be expensive and unnecessary to answer our basic question.  Instead, we would look to enable PMI on a single application only - wps - and monitor the session count of that application.

To enable PMI for the number of sessions on the wps application - perform the following steps:
1)  Login to the Deployment Manager / WAS Console
2)  Navigate to Monitoring and Tuning > Performance Monitoring Infrastructure > WebSphere_Portal
3)  In the configuration tab, select "Basic" if not already selected.  
4)  Save changes.  
5)  If in a cluster, repeat steps #2-#5 for each Portal server in the cluster.  Sync nodes.
6)  Restart the Portal server(s)

 

While more advanced PMI beyond the "Basic" setting can be enabled on the Portal server(s) - the Basic level is sufficient to answer our original question posed.



Monitoring Session Count

1)  Login to the Deployment Manager / WAS Console
2)  Navigate to Monitoring and Tuning > Performance Viewer > Current activity > WebSphere_Portal
3)  On the left-hand side, click the Plus (+) next to WebSphere_Portal > Performance Modules > Servlet Session Manager > wps#wps.war 
4)  Click "Start Monitoring"
5)  Repeat steps #2-#4 for each Portal server in the cluster.
6)  Navigate back to the wps#wps.war per Portal server to see the session count.

In the screenshot below, a single session / user logged in is shown for demonstration purposes:

In a live production system with hundreds or thousands of users logged in - you can monitor the activity over time to determine when peak loads may exist.

Introduction

WebSphere Portal end users can run into situations where cookies in the web browser are not always cleaned up properly.  It can be helpful to have code available which can remove cookies automatically and transparently to the end user.  In earlier versions of WebSphere Portal, this was accomplish through a quick bit of javascript code, often enabled in a custom theme.  With WebSphere Portal v8 and newer, the HttpOnly attribute is set on cookies which prevents javascript code from cleaning up the cookies.  Removing the HttpOnly attribute from the cookie is not recommended, as you leave your end users open to possible cross-site scripting attacks.

This article will explore an alternative method to clearing out cookies - use of a portlet on a WebSphere Portal page.  The code performs two functions:

1)  Clear out the JSESSIONID, LtpaToken, and LtpaToken2 cookies if present in the web browser.
2)  Redirect the user to a different location once the cookies are cleared


This article will also discuss setting up a page in WebSphere Portal where the portlet can be deployed, however, the page will not be visible to end users. 

A download link is available at the end of the article with sample code and a sample page in WebSphere Portal.

Setting up the Portlet

IBM Rational® Application Developer for WebSphere® Software v8.0.4 was used to develop this portlet.  However, any software which can create a JSR286 portlet with two-phase rendering capabilities can be used to author the necessary code.  Instructions will be detailed specific to Rational Application Developer.

1)  Create a new portlet project.  I called mine "cookieeater".

2)  Select a target runtime of WebSphere Portal 7.0 stub or later.  Do not add a project to an EAR.  Select JSR286-Basic API with Basic Portlet type.  Do not enable Web 2.0 Features.  Optionally, you my add an action listener, however it is not required for the code in the portlet.

3)  Open the portlet descriptor.  Add the a container runtime option of javax.portlet.renderHeaders with value true.

4)  Open the portlet descriptor.  Update the default namespace to a value of your choice.

*Note:   My end result in portlet.xml for steps #3-#4 looked like
<portlet-app>
...
<portlet>
...
</portlet>
<default-namespace>#default</default-namespace>
<container-runtime-option>
       <name>javax.portlet.renderHeaders</name>
       <value>true</value>
</container-runtime-option>
</portlet-app>
 

5)  Open the jsp file under your WebContent folder.  Add the following snippet of javascript code:

<script type="text/javascript">
<!--
window.location = "http://www.ibm.com"
//-->

*Note:  Modify this location to the actual location you wish to send end users after cookies are cleared out.  e.g. 

http://myportalserver.ibm.com:10039/wps/portal

6)  Open the java source code for your portlet.  Add the following two constants:

    final String PATH = "/";
    final String DOMAIN = "";
 

*Note:  Modify these two constants specific to your configuration.

7)  Add the following method to the source code:

public void doHeaders(RenderRequest request, RenderResponse response)

8)  Within the doHeaders method is where the cookie clearing logic occurs.  My code looked like the following:

Cookie[] cookies = request.getCookies();
        if (cookies != null)
        {
            for (Cookie cookie : cookies)
            {
                if (cookie.getName().equals("JSESSIONID") || cookie.getName().equals("LtpaToken") || cookie.getName().equals("LtpaToken2"))
                {
                    cookie.setPath(PATH);
                    cookie.setDomain(DOMAIN);
                    cookie.setMaxAge(0);
                    cookie.setValue("");
                    
                    response.addProperty(cookie);
                }
            }
        }

*Authors' note:  Removing the cookies does NOT perform a logout from WebSphere Portal!  Do NOT use this code as a substitute for logging out.

9)  Export your code to a WAR file.

10)  Done with coding!  Let's setup our Portal page with this portlet now.

Setting up the Portlet

1)  Deploy your cookieeater.war file via the "Web Modules" portlet

*Author's note:  I'm not sure why, but the web.xml file for my portlet contained the following stanza repeated multiple times <welcome-file-list>.  Portlet deployment initially failed as a result for me.  Manually cleaning up the web.xml file so only a single <welcome-file-list> stanza existed resolved the issue. 

2)  Create a new page in WebSphere Portal either via the Manage Pages portlet, or, via Edit Mode.  I called my page "eatme" and created it under the "Home" label.  Give it a friendly URL of "eatme".

3)  Add the cookieeater portlet to the page using either the Edit Page Layout portlet in Manage Pages, or, via Edit Mode.

4)  Navigate back to your Home label in your theme.  You should now notice a page called "eatme".

5)  Click the "eatme" page. 

- Your JSESSIONID, LtpaToken and LtpaToken2 cookies should be cleared out.

- You should be redirected to the site specified in the javascript of your jsp.

At this point, while the "eatme" page accomplishes 2 of 3 of our end goals, its sitting out there in plain site of end users.  Any user who happens to click on the page will have their cookies removed and will be forced to relogin to Portal.  Not good.  Next steps are to hide this page.

6)  Navigate back to your WebSphere Portal.  Log back in as an Administrator.

7)  Navigate to the Manage Pages portlet.  Click the 4th icon to "export" the page.

8)  Open the exported page.xml file.  Locate the following two lines:

            </pagecontents>
            <parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
 

9)  Update to the following, adding the new parameter "com.ibm.portal.Hidden" with value "true".

            </pagecontents>
            <parameter name="com.ibm.portal.Hidden" type="string" update="set"><![CDATA[true]]></parameter>
            <parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
 

10)  Save changes.

11)  Navigate to the Import XML portlet in the Administration area.

12)  Import the updated page.xml with the new page parameter added.

*Author's note:   Any page parameters that begin with com.ibm.portal.* cannot be set via the GUI.  The only means to set them is through XMLAccess scripting.

13)  The "eatme" page should no longer be visible within your Portal site.

14)  Test the Friendly URL of the page, e.g.

http://myportalserver.ibm.com:10039/wps/myportal/Home/eatme

15)  Your cookies should be removed and you should be redirected to the site specified in the javascript of your jsp.

16)  (Optional):  Set anonymous permissions on the page and portlet.

17)  Enjoy!  Feel free to implement and modify for your own specific Portal site.  You should be able to send users to this friendly URL as needed within your Portal site to clear out cookies.

Sample End Result Portlet and Page

https://greenhouse.lotus.com/files/app/file/f7930521-d50e-4f23-b628-9a452df64bac

Creating a new theme in WebDAV:

In Websphere Portal v7, themes are broken apart into static template files and dynamic files. The static template files are stored in WebDAV and use dynamic content spots to reference JSPs or other dynamic resources. The dynamic resources are stored in a WAR file. WebDAV directories include files for the following theme functionality: theme, skin and layouts.

The following steps will create a new theme in portal using WebDAV.

1. Using a WebDAV client Connect to http://<server>:10039/wps/mycontenthandler/dav/themelist/
2. Copy the csa2.theme to your local directory
3. Rename the csa2.theme folder on your local system to sample.theme
4. Update the metadata\localized_en.properties to reflect the new title. You would need to modify each localized properties file for each languange.
5. Modify the theme_en.html file so that you can verify the correct theme is applied. This file is found in the nls directory
   For example:
   <body class="lotusui tundra locale_en" >

   Sample Theme<br>
   
   

6. Copy the sample.theme folder to the themelist entry point using the web dav client.
7. In portal create a new page named Sample Theme and apply the Sample Theme theme using the admin portlet, best practice is to create the page using the edit mode of the theme, however creating it through the admin portlet will reveal some differences in page types in 7.0, and a common customer scenario.
8. Render the page and verify that your theme_en.html is being rendered. You should see the text ?Sample Theme? rendered on the page
   
   

   
   

9. Modify your theme_en.html to the following:
   <body class="lotusui tundra locale_en" >

   Sample Theme Modified<br>
   
   Copy the modified theme_en.html back to the server using the themelist entry point
   Do you see the update?
   
   

10. By default the WebDAV files are cached for 24 hours. You will need to change the cache values during theme development in order to see the changes immediately.
    
    Open the WSAS admin console and go to the WP_ConfigService Resource Evironment Provider (REP) Resources ->Resource Environment ? Resource Environment providers
    In the custom properties you will see several entries like the following:
    
    
    Please see the following section in the infoCenter for more details about this caching:
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Using_WebDAV_file_store_for_the_Page_Builder_theme_and_mashup_integration_wp7
    
    Change all of the following entries to a value of 1 and restart the server. This will reduce the caching for the WebDAV files to 1 second.
    filestore.cache.expiration.0.seconds
    filestore.cache.expiration.1.seconds
    filestore.cache.expiration.2.seconds
    filestore.cache.expiration.3.seconds
    
    Render the page again and you should see the modified output from the theme_en.html
    
    

note: best practice is to use the fs-type1 entry point for modifying the files and not the themelist entry point. The themelist entry point is an admin entry point and is used for altering theme metadata including the titles. Please note the cache above will only effect the themelist entry point not the fs-type1. As an additional exercise reset the caching to default values, restart the server, and then make a change via the fs-type1 entry point and see that your changes are immediately visible.

Now that the new theme is created lets take a few minutes to understand what happened by generating a complete xmlAccess export of the server using the following technote:

http://www-01.ibm.com/support/docview.wss?uid=swg21260098

Note that you will be using this XMLAccess export in a future step.

You should now see a theme defined like the following (the objectid may be different):

<theme action="update" active="false" context-root="/PageBuilder2" default="false" domain="rel" objectid="ZJ_4GFA8VO20G3ID0IMR5PK562006" resourceroot="PageBuilder2">

....

<localedata locale="en">

<title>Sample Theme</title>

<description/>

</localedata>

....

<parameter name="theme.capability.dojo" type="string" update="set"><![CDATA[1.4.3]]></parameter>

<parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[sample.theme]]></parameter>

<parameter name="com.ibm.portal.themetype" type="string" update="set"><![CDATA[CSA2]]></parameter>

<parameter name="theme.capability.oneUI" type="string" update="set"><![CDATA[2.1]]></parameter>

<parameter name="com.ibm.portal.theme.template.ref" type="string" update="set"><![CDATA[dav:fs-type1/themes/sample.theme/]]></parameter>

<parameter name="theme.capability.mashups.enabler" type="string" update="set"><![CDATA[2.4]]></parameter>

</theme>

The newly created sample theme is using the PageBuilder2 war file. This can be seen from the context-root and resourceroot attributes. There are also several parameters defined for the theme. If present, the ?com.ibm.portal.friendly.name? parameter is used as the display name for the theme in the themelist webDAV entry point. This should be a unique value in the system but this is not enforced. If the ?com.ibm.portal.friendly.name? parameter is not available then the uniquename of the theme is used as the display name. If neither the ?com.ibm.portal.friendly.name ? or the uniquename are defined for the theme then the theme's OID will be used as the display name.

The themelist webdav entry point mirrors the fs-type1 entry point. Since the themelist uses the ?com.ibm.portal.friendly.name as the display name it has to be unique. If there are two themes that have the same value, only one will be displayed.

When our sample theme is rendered the default.jsp of the PageBuilder2 WAR is the main entry point. The default.jsp will then call the correct theme.html file to execute. It determines the correct path by using the com.ibm.portal.theme.template.ref parameter.

Creating a new theme WAR file

The theme WAR file will contain the dynamic resources. As stated in the previous section the default.jsp of the

PageBuilder2 theme is used when our sample theme renders. If you want to modify the default.jsp or any of the dynamic resources you should create a new WAR to contain them.

1. Copy the following WAR into a temporary working directory:

<portal install>\theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuilder2.war

2. In Rational Application Developer (RAD) or Eclipse, create a new Dynamic Web Application titled PageBuilder2 theme from the temporary working directory you created above for the new WAR.

   I created a new project then pasted the contents of the war directory into the web content directory
   
   

3. Open up the web.xml and change the display name to ?SampleTheme?
   <display-name>SampleTheme</display-name>
   
   
4. Under the themes\html directory your will see a folder named PageBuilder2. Rename this directory to SampleTheme. This directory name will be used as the resourceroot in a later step so if you name it something different you will need to update the resourceroot later.
   
   
5. We will also add some content to the Default.jsp so that we can verify the correct theme is being picked up.
   Open the default.jsp and add the following code right after the include to the bootstrap.jspf:(this default.jsp will be in the root html directory not in the theme directory
   <%@include file="./bootstrap.jspf" %>

   SampleTheme Default.jsp<br>
   
   

6. Export the WAR from RAD
   
7. Import the WAR into the WSAS admin console.
   When importing the theme use ?/sampletheme? as the context root for the theme. This will be used in a later step for the ?context-root? in the xmlAccess file. If you name this differently you will also have to change the context-root value in later steps.
8. Start the application in the WSAS admin console
   
9. We will use the xmlAccess export from a previous step to change the context-root and resourceroot of the sample theme to point to the newly created WAR file.

   Note: Please refer back to step 4 and step 7 if the values for context-root and resourceroot are not clear.
   
   Example :
   <?xml version="1.0" encoding="UTF-8"?>

   
   <request build="wp700_606_01" type="update" version="7.0.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
   <portal action="locate">
   <theme action="update" active="false" context-root="/sampletheme" default="false" domain="rel" objectid="ZJ_4GFA8VO20G3ID0IMR5PK562006" resourceroot="SampleTheme">
   <localedata locale="en">
   <title>Sample Theme</title>
   <description/>
   </localedata>
   <parameter name="theme.capability.dojo" type="string" update="set"><![CDATA[1.4.3]]></parameter>
   <parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[sample.theme]]></parameter>
   <parameter name="com.ibm.portal.themetype" type="string" update="set"><![CDATA[CSA2]]></parameter>
   <parameter name="theme.capability.oneUI" type="string" update="set"><![CDATA[2.1]]></parameter>
   <parameter name="com.ibm.portal.theme.template.ref" type="string" update="set"><![CDATA[dav:fs-type1/themes/sample.theme/]]></parameter>
   <parameter name="theme.capability.mashups.enabler" type="string" update="set"><![CDATA[2.4]]></parameter>
   </theme>
   </portal>
   </request>
   
   

   Note: You will need to use the information from your export since the OIDs will be different. You cannot use the xml above.
   
   

10. Import the modified xml file using xmlAccess. You can do this by simply navigating to the Portal Administration Console and choosing the import XML option and then pointing to the updated xml file for the theme.
    
    
11. Now render the page again and you should the following:
    

    

12. Now modify the bannerNav.jsp to add some additional markup.
    Example:
    Sample Theme bannerNav.jsp<br >

    <%-- Renders the links in the banner (Home, Admin, etc.) server side --%>

13. Rebuild the WAR and then update it in the WSAS admin console.
14. Refresh the page, do you see the updated markup you added in the bannerNav.jsp?
    You should not see your changes in the bannerNav.jsp

The default.jsp of the Sample Theme is used when rendering the page with the theme applied. However as stated previously the default.jsp will call the static theme template that is defined in the themes metadata. For the sample theme
it uses the following:

dav:fs-type1/themes/sample.theme/

If you inspect the theme_en.html file you see the following dynamic-content-spot that is used to render the bannerNav.

<!-- responsible for the top most navigation links (horizontal list) -->

<a rel="dynamic-content" href="dyn-cs:id:bannerNav@tl:oid:csa2.theme"></a>

This markup will inform the static page parser in WebSphere Portal to look for dynamic-content-spot with an id of bannerNav. You will also notice that the href contains @tl:oid:csa2.theme. This instructs the static page parser to look in the theme with a uniquename of csa2.theme for any dynamic-content-spot overrides. All this means is that your theme is still using the bannerNav.jsp from the PageBuilder2 WAR file and not from your custom SampleTheme WAR.

If you want it to your content spots to pull from your custom war you would need to change them to reference your custom war.
You have three options:
Please see the following section of the InfoCenter for more details http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Working_with_dynamic_content_spots_wp7

• Defining a custom content spot via the resource environment provider
• adding an override to the theme metadata
• changing the href to be a resource url
  <a rel="dynamic-content" href="res:/sampletheme/themes/html/SampleTheme/bannerNav.jsp"></a>

One of the more common type of "health check" errors that may occur during a fixpack installations is a failure during its xmlaccess test section. You may receive a BUILD FAILED message that looks like this:

Server validation failure: XMLAccess test script failed.  Please ensure that your WebSphere_Portal server is functional and that PortalAdminPwd, WasPassword, XmlAccessHost, XmlAccessPort, WpsHostName, WpsHostPort, and database passwords are all correct in their respective C:/IBM/WebSphere/wp_profile/ConfigEngine/properties files.  After doing so, rerun the PTF.

 This often indicates that some of the properties you have listed above are not correct or that the server is not resolving properly to either its host name or local host.

This simple troubleshooting script can often help with finding out the culprit:

1. On the portal server, open a command window and change to the <profile>/PortalServer/bin directory.

2. Copy this file:

<WAS_root>/PortalServer/base/wp.xml/doc/xml-samples /Task.xml  to the <profile>/PortalServer/bin directory

3. Enter this command replacing all < > entries with your Portal's values:

xmlaccess.bat|sh -in Task.xml -user <PortalAdminPwd> -password <admin pwd> -url http://<portal hostname>:<port>/wps/config -out results.xml

By testing both the localhost name, fully, qualified host name, port, and expected PortalAdminPwd you can often determine what may be off with your properties settings.

Here is an example of a failed run of the command:

C:\IBM\WebSphere2\wp_profile\PortalServer\bin>xmlaccess.bat -in Task.xml -user wpsadmin -password xxxxxxxx -url http://IBMD1.ibm.com:10040/wps/config -out resul

ts.xml

Licensed Materials - Property of IBM, 5724-E76, 5655-R17, and 5655-M44, (C) Copy

right IBM Corp. 2001, 2007 - All Rights reserved. US Government Users Restricted

 Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract

 with IBM Corp.

EJPXB0006I: Connecting to URL http://IBMD1.ibm.com:10040/wps/config

EJPXB0004I: Writing output file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\results.xml

EJPXB0002I: Reading input file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\Task.xml

EJPXB0019E: Server response indicates an error. For status and details of the XmlAccess error look at file results.xml.

Here is an example of a successful run of the command:

C:\IBM\WebSphere2\wp_profile\PortalServer\bin>xmlaccess.bat -in Task.xml -user wpsadmin -password wpsadmin -url http://IBMD1.ibm.com:10040/wps/config -out results.xml

Licensed Materials - Property of IBM, 5724-E76, 5655-R17, and 5655-M44, (C) Copy

right IBM Corp. 2001, 2007 - All Rights reserved. US Government Users Restricted

 Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract

 with IBM Corp.

EJPXB0006I: Connecting to URL http://IBMD1.ibm.com:10040/wps/config

EJPXB0004I: Writing output file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\results.xml

EJPXB0002I: Reading input file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\Task.xml

<!-- 1 [task name=com.ibm.portal.datastore.task.ResourceCleanup] -->

EJPXB0020I: The request was processed successfully on the server.