Когда мы недавно добавили новый узел в наш кластер WebSphere Portal / WCM 6.1.5.2, у нас возникла очень странная проблема.

Наше приложение использует встроенные функции авторинга в портлете локального рендеринга. Настройка довольно стандартная. У нас есть компонент меню, который мы используем для отображения контента из области сайта. В компоненте у нас есть ссылка на инструмент разработки для каждого элемента контента, например:

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

«Editauthoringtool» - это стандартный компонент «Инструменты разработки» с действием редактирования.

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

Теперь о странном. При просмотре страницы с использованием этих компонентов на одном из наших серверов отображается правильная встроенная ссылка на URL-адрес авторинга с href, содержащим javascript-вызов автоматически сгенерированного метода ..._openInlineEditingDialog(), который выглядит примерно так:

<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>

Однако при доступе к той же странице на другом узле кластера созданные ссылки редактирования НЕ предназначены для встроенного редактирования. Вместо этого сгенерированные ссылки предназначены для прямого доступа к странице wcmAuthoring, а не для встроенного встроенного стиля, выглядящего примерно так:

<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>

Кто-нибудь еще видел что-нибудь подобное, что два узла в одном кластере портала могут вести себя по-разному? Мы копались, пытались найти интересные различия на уровне файлов между серверами, но пока безуспешно. Версия кажется одинаковой на двух узлах. PortalServer \ wps.properties выглядит одинаково в обоих:

# 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 показывает, что оба узла находятся на одном уровне исправлений, однако один из них имеет явные записи для предыдущих пакетов FixPack (WP_PTF_6102, WP_PTF_6103)

Узел 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)

Узел 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)
1
pap 30 Авг 2011 в 17:09

2 ответа

Лучший ответ

После долгой и напряженной работы мы обнаружили, что для исправления этой ситуации нам нужно добавить wcm.fp.enabled=true в файл WCMConfigServices.properties.

1
pap 22 Сен 2011 в 07:38

Странная проблема. Если вы разделяете jar-файлы в PortalServer / wcm / prereq.wcm / shared / app между каждым сервером, они одинаковы? Это портлет JSR286 или устаревший портлет?

0
bortoelnino 5 Сен 2011 в 07:30