More tales from the front-line - Ephox EditLive! Rich Text Editor failing to load in WCM 6.1.0.3

Environment

Red Hat Enterprise Linux 5.5
WebSphere Application Server Network Deployment 6.1.0.27
Java pxi32devifx-20090811 (SR10 +IZ56666+IZ56751)
WebSphere Portal / Lotus Web Content Management 6.1.0.3 ( plus PM02927 / PM13199 / PK84963 / PM02565 )

Deployed as a two-node cluster, managed by a separate Deployment Manager, with a pair of front-end web servers ( IBM HTTP Server 6.1.0.29 )

In addition, context root of portal has been changed from /wps/portal to /london/portal via the ConfigEngine modify-servlet-path command, as per: -

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

Overview

Ephox EditLive! Rich Text Editor (RTE) does not render when using WCM in a clustered environment - assumption is (a) that clustering has caused this exception or (b) that changing the default context root for the portal from /wps/portal to /london/portal.

Recreation Steps ( using Firebug 1.5.4 plugin within Firefox 3.6.3 to trap )

- Configure WCM Authoring Portlet to use EditLive as default editor, by setting Extended Editor under Rich Text Options
- Edit a piece of web content that has a Rich Text element within it
- Firebug throws up the Script exception: -

editlivebaseurl is not defined @ Line 658

>From the source of the page: -

<script language="Javascript" type="text/javascript" src="/wps/PA_WCM_Authoring_UI/wps/ephox/res/editlivebaseurl.js"></script>

it appears that Ephox is attempting to load the following JavaScript file: -

/wps/PA_WCM_Authoring_UI/wps/ephox/res/editlivebaseurl.js

which implies that the JS is available within the WCM Authoring application.

However, there is only one instance of this JS file on disk: -

/opt/IBM/WebSphere/wp_profile/installedApps/cellnameCell01/EphoxEditLive.ear/EphoxEditLive.war/res/editlivebaseurl.js

This is referenced in the EditLive JSP: -

/opt/IBM/WebSphere/wp_profile/installedApps/cellnameCell01/EphoxEditLive.ear/EphoxEditLive.war/jsp/html/EditLiveJavaEditor.jsp

<%-- used to load the portal Base URL in a way that is picked up by webseal --%>
<script language="Javascript" type="text/javascript" src="<%= portletResponse.encodeURI(getServletContext().getAttribute("directory") + "/res/editlivebaseurl.js") %>"></script>

Circumvention

Use absolute URL to JavaScript: -

http://portal.uk.ibm.com:10040/wps/ephox/res/editlivebaseurl.js

as JS is in DIFFERENT enterprise application ( EphoxEditLive ) and corresponding web application ( EphoxEditLive.war ) to WCM authoring ( PA_WCM_Authoring_UI  and ilwwcm-authoring.war respectively )

- Backup EditLiveJavaEditor.jsp
- Edit EditLiveJavaEditor.jsp
- Comment out: -

<%-- used to load the portal Base URL in a way that is picked up by webseal --%>
<script language="Javascript" type="text/javascript" src="<%= portletResponse.encodeURI(getServletContext().getAttribute("directory") + "/res/editlivebaseurl.js") %>"></script>

- Insert: -

<script language="JavaScript" type="text/javascript" src="http://portal.uk.ibm.com:10040/wps/ephox/res/editlivebaseurl.js")></script>

Alternatively, use an absolute URL to the web server(s) sitting in front of the portal cluster e.g.

<script language="JavaScript" type="text/javascript" src="http://webserver.uk.ibm.com/wps/ephox/res/editlivebaseurl.js")></script>

having checked that the Ephox web application, EphoxEditLive.war, is mapped to the HTTP servers as well as to the cluster.

Having made the above amendment to the EditLiveJavaEditor.jsp file ( on BOTH nodes within the cluster ), it's then necessary to restart the cluster having, for good measure, cleared down the temp and wstemp directories: -

rm -Rf /opt/IBM/WebSphere/wp_profile/wstemp/*
rm -Rf /opt/IBM/WebSphere/wp_profile/temp/*

to remove any compiled versions of edited JSP.

Once the cluster is restarted, the EditLive RTE now works as expected.

The circumvention does the trick - in the meantime, I've raised a PMR with IBM Support ...

Thanks be to Adrian Sutton of Ephox for his timely support, both via Twitter (!) and the telephone