Develop WebSphere Portal 8 Portlets without RAD

My buddy Gabriel posted a great article about creating portlets for IBM WebSphere Portal 8 without the need for RAD (Rational Application Developer) by creating some simple, custom actions in the Eclipse IDE.  Great stuff, and I can't wait to try it out!

See the article here: http://theoreticaltechstuff.blogspot.com/2013/12/creating-portlets-without-rad-ibm.html?showComment=1386859313424#c3336981388793430830

IBM Launchpad Will Not Start: Unable to find supported browser

I encountered this issue when attempting to start the launchpad to start an IBM WebSphere Portal 8 installation via the IBM installation manager - took me a while to sort out, so hopefully this write-up will save someone else some time!

When trying to fire up the IBM Launchpad application via the Setup.sh command on a system where Mozilla Firefox 17+ is configured as the default browser, you may receive an error message in your browser:

Unable to find supported browser

An error occurred while starting the launchpad. This error typically occurs when the launchpad is unable to find a supported browser. Check your product's documentation for a list of supported browsers.
NOTE: This file is a place holder for product specific instructions about how to recover from this error.
You should describe the location of installation programs on the product CD so the user can run them directly without starting launchpad if necessary.
Procedure for correcting the error that is preventing the launchpad from displaying
==============================================================
The launchpad supports the following browsers:
o Mozilla
o Firefox
o Internet Explorer (Microsoft Windows platforms only)
o SeaMonkey

With a little digging, you'll discover that the whichBrowser variable in launchpad\browser.sh script (called by Setup.sh) is actually being set correctly, and that your browser is being opened with the following, valid command:

/usr/bin/firefox -P Profile_2883 -profile /tmp/IBM_LaunchPad_2883/Profile_2883 file:///media/sf_websphere_media/media_80/wp_package/Setup/launchpad/Mozilla.html

This will immediately redirect you to file:///media/sf_websphere_media/media_80/wp_package/Setup/launchpad/en/noBrowser.html - it may not even be apparent that a redirection occurs, which can be frustrating.

What's happening here is that the javascript file "Mozilla.js" (called from "Mozilla.html") is attempting to make a netscape.security.PrivilegeManager.enablePrivilege call, which is no longer supported by Firefox.  This throws a javascript error, which triggers the redirect.

Mozilla.js Line 43: netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

Support for enablePrivilege has been removed in Firefox (Bug 546848), so it is no longer possible to get special elevated privileges by using this method.

For details about the change to Firefox, the following support note: http://support.mozilla.org/en-US/questions/944433


To get around this problem, I installed an older version of Firefox (10.2).  Once I did this, everything worked great!  You can find older versions of Firefox here:  https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

Happy Portalling!

CentOS 6 Minimal Desktop Install Tip

I've had to do this a few times, and I always forget the commands - this time I stumbled upon jbmurphy's blog and an old post that already had the information I needed:

yum groupinstall basic-desktop desktop-platform x11 fonts

http://www.jbmurphy.com/2011/12/01/how-to-add-gnome-to-centos-6-minimal-install/

Thanks JBM :)

Direct to Server URL Loses Port Number (WebSphere Portal 6.1)

I recently encountered a situation that required direct-to-node testing of one server in my portal cluster, so I looked up the default port for this server and typed in my internal URL:  http://myserver:10048/wps/portal... It was immediately obvious that something was wrong when the IBM logo and the login button did not render correctly.

I attempted to log in anyway... 404.  I noticed that the URL was incorrect in that the server-specific port had been removed, so my URL looked like this:  http://myserver/wps/myportal/...

It took a little digging, but I was able to find and resolve the problem with the following steps.

In the Deployment Manager

1. Navigate to Resources -> Resource Environment Providers
2. Click WP_ConfigService
3. Click Custom Properties (on the right)
4. Clear the http.host.port property (mine was 80)
5. Clear https.host.port property to (mine was 443)
6. Sync the cluster and restart the portal servers

Blank values for http.port and https.port

Happy portalling!

Hiding Portal Pages from Navigation (WP 6.1)

Hiding portal pages (and other items) from Portal Navigation is a common requirement, but there is no obvious way to do this.  There are some suggestions that using the Manage Pages portlet works, though I have not had any success with it.  My personal approach requires xmlaccess, but has never let me down!  Here's how I do it:

First, use xmlaccess to export the page, label, or other item(s) that you need to hide from navigation.  For a brief tutorial about xmlaccess exporting, the following article may be helpful: http://www-01.ibm.com/support/docview.wss?uid=swg21260098

Following is a snippet from a Portal 6.1.0.3 xmlaccess export that I took - it has been mangled slightly to fit on the page.  The parameter in question is highlighted in red.  If your export does not contain this parameter, just copy / paste from this article and it should work fine.

        <content-node action="update" active="true" allportletsallowed="false" create-type="explicit" domain="rel".... >
            <supported-markup markup="html" update="set"/>
            <localedata locale="en">
                <title>Enterprise Search for classic collections</title>
            </localedata>
            <parameter name="colorPalette" type="string" update="set"><![CDATA[bcbstp2Theme/bcbstp2Theme]]></parameter>
            <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>
            <parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[No]]></parameter>
            <parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[OmniFindSearch]]></parameter>
            <parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA[0]]></parameter>
            <parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>

If the parameter already exists, just change the value within the CDATA block to "true" (to hide the page) or "false" (to show the page), depending on what you need.

Once you're done, save the xmlaccess file (make sure you keep a back up of your original export!) and reimport to your server.  The changes should be visible to Portal Navigation on the next reload.

Happy Portalling!

Memory Analysis - Gathering Java Cores on Windows WebSphere Servers

After dealing with a few memory leak issues in a windows-based, production environment, I have found the following steps to be most useful for gathering java cores to analyze for potential memory leaks.  

Download the Microsoft Debug Diagnostic Tool v1.2 http://www.microsoft.com/download/en/details.aspx?id=26798

Download the tool appropriate to your environment (32b vs. 64b)

Install the tool with default settings.

Launch the tool.

Cancel the "Rules Wizard" (if it shows up)

Click the "Processes" tab.

Select the java.exe process to be monitored.

Right click and select "Monitor for Leaks".

Wait about 15 minutes after starting the server, then right click the monitored java.exe and select "Create Full Userdump

1.                Install and take the defaults

2.                Launch Debug Diagnostic Tool

3.                Cancel the "Rules" wizard if it pops up

4.                Go to processes tab

5.                Locate the java.exe that you suspect to be leaking memory

6.                Right click and select "monitor for leaks"

7.                After 15 minutes, right click on the same java.exe from step 5 and select "Create Full Userdump"

8.                Depending how log it takes for memory to grow (minutes, hours, days, weeks...) collect 2 more userdumps over time for comparison analysis

9.                Review dumps by clicking the Advanced Analysis tab

10.              Click the "Add Data Files" button

11.              Locate dumps (default: <Debug_Diag_Install_Dir>\Logs\Misc)

12.              Select  the dumps from the same PID that you created in step 7

13.              Select "MemoryAnalysis.asp"

14.              Click "Start Analysis"

Adding LDAP Attributes to WebSphere Portal 6.1

When using an external directory for security in WebSphere Portal 6.1, you may find that some of the attributes in your directory are not available to applications, even through direct PUMA calls.  This is because WP only has default access to a base set of default attributes and anything outside of this set has to be mapped manually.

Adding these attribute mappings for WebSphere Portal 6.1 can be a little tricky, but once you've done it a few times it gets easier.  The following article attempts to provide a concise list of the steps required to add custom LDAP Attributes to your IBM WebSphere Portal 6.1 cluster.

The full IBM InfoCenter document can be found here: http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1/index.jsp?topic=/com.ibm.wp.exp.doc_v6101/install/i5os_add_attributes.html

Special thanks to Gabriel Boie (http://theoreticaltechstuff.blogspot.com) for providing clarifying information regarding this task!

I will assume that you already have a valid LDAP configuration and that you know your primary node's profile path and can find both the ConfigEngine.sh/bat and wkplc.properties files.  

Install WIMSystem.ear
This config engine task installs the WIM application required to add and map the new LDAP attributes.

• Stand-Alone:

ConfigEngine.bat wp-la-install-ear -DWasPassword=password

• Clustered:  This must be run on the primary node, but the Server and Node name parameters are for the deployment manager.

ConfigEngine.bat wp-la-install-ear -DWasPassword=password –DServerName=server_name –DNodeName=node_name 

• Restart the Cluster.

Add the LDAP Attributes

• Backup the wkplc.properties file in your primary node, then open it in a text editor.
• Find and update the following properties with values that meet your needs - the following is an example specific to my environment.

la.providerURL=corbaloc:iiop:localhost:10031
la.propertyName=extendedAttribute01
la.entityTypes=PersonAccount
la.dataType=String
la.multiValued=true

• Save the wkplc.properties file and execute the following ConfigEngine command:

ConfigEngine.bat wp-add-property -DWasPassword=password

TIP: A connection refused error will occur if the providerURL address and/or port are incorrect.  Check your server settings for address and port. 

TIP: A NameNotFoundException following a message stating that the WIMServiceHome EJB could not be found will likely occur if you neglect to restart the cluster after installing or reinstalling WIMSystem (wp-la-install-ear). 

TIP: An error stating that the service must be run on the deployment manager (paraphrased, I don't have the exact message, sorry) most likely indicates that WIMSystem.ear was installed using an incorrect server and/or node name.  The following technote addresses this situation: http://www-01.ibm.com/support/docview.wss?uid=swg21383774 

TIP: Provide LDAP credentials at the prompt.  Your bind account should have write access, though these mappings are possible without them.

• REPEAT the steps under "Add the LDAP Attributes" once for each attribute you need to add. 

Map LDAP Attribute Names in Portal

For the final step, we have to map the LDAP attribute names to Portal attribute names.  This simple process is described in http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1/index.jsp?topic=/com.ibm.wp.exp.doc_v6101/install/i5os_add_attributes.html.  The following example applies to standalone LDAP only!  For federated LDAP, reference the aforementioned infocenter document.

• Update your wkplc.properties files with the appropriate LDAP names, desired portal names, and matching entity types.

standalone.ldap.attributes.mapping.ldapName= extensionAttribute2, extensionAttribute6, extensionAttribute8, extensionAttribute10, extensionAttribute11, extensionAttribute13

standalone.ldap.attributes.mapping.portalName= DepartmentCode, DivisionCode, ManagerCode, EmployeeGrade, BuildingName, BusinessUnit

standalone.ldap.attributes.mapping.entityTypes=PersonAccount, PersonAccount, PersonAccount, PersonAccount, PersonAccount, PersonAccount

Execute the following ConfigEngine task:

• ConfigEngine.bat|sh wp-update-standalone-ldap-attribute-config -DWasPassword=password