WebSphere Portal 6.1.5.2, Lotus WCM, inline authoring works in one cluster member, not the other

Question

A very odd issue turned up for us when we recently added a new node to our WebSphere Portal/WCM 6.1.5.2 cluster.

Our application makes use of the inline authoring functionality in the local rendering portlet. The setup is fairly standard. We have a menu component we use to display content from a site-area. In the component, we have an authoring tool reference for each content item like so:

<Component name="admin library/editauthoringtool" compute="always"/>

The "editauthoringtool" is a standard "Authoring tools" component with edit action

<a href="<Placeholder tag="href"/>"  class="icon-edit" title="Edit"></a>

Now for the odd bit. When viewing a page using these components on one of our server, a correct inline authoring url link is rendered with an href containing a javascript call to the auto-generated ..._openInlineEditingDialog() method - looking something like this:

<a title="Edit" class="icon-edit" href="javascript:ns_7_CES00SD30GCN80I6UTMJF50MO2_openInlineEditingDialog('?uri=dialog%3awcm&amp;docid=com.aptrix.pluto.content.Content%2f8e87e6804822e81a832a973e18750505&amp;action=edit', 'Edit');"></a>

However, when accessing the same page on the other cluster node, the editing links generated are NOT for inline editing. Instead, the links generated are for direct access to the wcmAuthoring page, rather than the embedded inline style - looking something like this:

<a title="Edit" class="icon-edit" href="/isip/myportal/sehm1/wcmAuthoring/!ut/p/c5/rZBJdoJAAETP4gm6MciwZGpkaAjSKLDhYaARZOigAeX0IbtskpVV-_r_FUjB2j6f6iq_10OftyAGqZBpRghhqL9BU3U5aCm6YWlOsFdsDpxADPksbJ7MWq7LoRGDGTdHzxuTGevIJiOyyLV1w-vdJxFzwyWasRvBcEEe_JC5IwoMBQtm10qbdSv9ocE_okDg7YeuBAlIxV9OmidBS4gIttEOYh8C8kKn_1nbl7JskFbtcF5fP9nJU9YGPCMjpYekmORC-OpDLsodM2DnETl6WtHhEg9dRqEp9rpfBCTj9jYSVd5-LAmkcefryoWbZHXgGfFVu94ly9IpZMKPMn9vVIsGZiEw8ViyLeWEz8tjS0hN-VFiTl6wqmjL-nafSFSpWODcOBZuIm-snqybmORRj2Jl8w0ZzF56/dl3/d3/L0lDU0lKQ2dwUkNncFJBISEvb0VvUUFBSVF4QkFJRW95akNVNExnaWNBLzRCRWo4TUF4RW1TQ1VRcE1tRW9SLzdfQ0VTMDBTRDMwR0JMMTBJQURFSUNLUUhRUDUvNl9DRVMwMFNEMzBHQkwxMElBREVJQ0tRSFFQNC93Y21BdXRob3JpbmdBY3Rpb24vZWRpdC9kb2NpZC9jb20uYXB0cml4LnBsdXRvLmNvbnRlbnQuQ29udGVudCUwOGU4N2U2ODA0ODIyZTgxYTgzMmE5NzNlMTg3NTA1MDU!/"></a>

Has anyone else seen anything similar, that two nodes in the same portal cluster can behave so differently? We've been digging around, attempting to find interesting diffs on a file-level between the servers, but no luck yet. Version appear to be the same on the two nodes. PortalServer\wps.properties looks the same in both:

# Product information for IBM WebSphere Portal Server
product=IBM WebSphere Portal Server
version=6.1.0.5
featurepack=6.1.5.2
fixlevel=0
mode=standard
buildnumber=wp6105_021_01
WPFamilyName=content
WPInstallType=full

VersionInfo.log shows that both nodes are at the same patch-level, however one of them have explicit entries for previous FixPacks (WP_PTF_6102, WP_PTF_6103)

Node 1:

------------------------------------------------------------
IBM WebSphere Portal 6.1.0.5
Build Level: 20110228.0705D (2011-02-28 07:09)
Server Name: ****
Started at:  8/18/2011 13:41:41:465 CEST

Installed Feature Packs:
    IBM WebSphere Portal FeaturePack 6.1.5.2 (FEAT615 wp6105_021_01 2010-09-17 09/17/2010)
Installed FixPacks:
    WP_PTF_6102 (IBM WebSphere Portal, Version 6.1.0.2 Fix Pack)
    WP_PTF_6103 (IBM WebSphere Portal, Version 6.1.0.3 Fix Pack)
    WP_PTF_6105 (IBM WebSphere Portal, Version 6.1.0.5 Fix Pack.  If Feature Pack 615 is installed, it will also be updated.)
Installed Interim Fixes:
    PM22198 (During incremental crawling url is not updated in the index)
    PM31611 (Cumulative fix #12 (CF012_PM31611) for Portal 6.1.0.5)
    PM32059 (Cumulative iFix 43 for WCM v6.1.0.3, v6.1.0.4, v6.1.0.5)

Node 2:

------------------------------------------------------------
IBM WebSphere Portal 6.1.0.5
Build Level: 20110228.0705D (2011-02-28 07:09)
Server Name: ****
Started at:  8/18/2011 13:47:35:426 CEST

Installed Feature Packs:
    IBM WebSphere Portal FeaturePack 6.1.5.2 (FEAT615 wp6105_021_01 2010-09-17 09/17/2010)
Installed FixPacks:
    WP_PTF_6105 (IBM WebSphere Portal, Version 6.1.0.5 Fix Pack.  If Feature Pack 615 is installed, it will also be updated.)
Installed Interim Fixes:
    PM22198 (During incremental crawling url is not updated in the index)
    PM31611 (Cumulative fix #12 (CF012_PM31611) for Portal 6.1.0.5)
    PM32059 (Cumulative iFix 43 for WCM v6.1.0.3, v6.1.0.4, v6.1.0.5)

Answer 1

After much, long hard work we found that to fix this, we had to add wcm.fp.enabled=true to the WCMConfigServices.properties file.

Answer 2

Whoa, that's a strange problem. If you diff the jars in PortalServer/wcm/prereq.wcm/shared/app between each server, are they the same? Is this in the JSR286 portlet, or the legacy portlet?