A customer encountered a problem with our platform Aveedo after upgrading their server to the latest FP5. XPages that contain a view or folder could not be opened anymore and threw an exception:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1
com.ibm.xsp.domino.context.DominoExternalContext.encodeResourceURL(DominoExternalContext.java:323)
com.ibm.xsp.renderkit.html_extended.RenderUtil.writeLinkAttribute(RenderUtil.java:191)
com.ibm.xsp.renderkit.html_extended.LinkRendererEx.encodeBegin(LinkRendererEx.java:187)
com.ibm.xsp.renderkit.ReadOnlyAdapterRenderer.encodeBegin(ReadOnlyAdapterRenderer.java:146)
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:956)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:841)
A quick check on 11.0.1FP4 showed that the app runs fine - the same is for a server of version 12.0.x.
Thanks to the help from Martin Pradny I could identify the problem in the file lwpd.xsp.domino.jar
which resides in the directory
<DominoProgram>/osgi/shared/eclipse/plugins/com.ibm.xsp.domino_xxx/
on your server. The version number depends on your Domino version.
After a quick unzip of the JAR and de-compilation of the DominoExternalContext.class file for all versions of this file (11.0.1FP4, 11.0.1FP5 and 12.0.1IF2) I was able to check the differences, and it turned out, there is one in FP5:
This is the "old" code in FP4 and 12
and this is the new code in FP5
The line numbers do not match to those in the stack as the de-compiler skipped any comments etc. But as this is the only difference and also could produce this kind of error, I am pretty sure it's the reason for the problem.
Martin also pointed me to a fix list entry which also seems to be reasonable for this part of the code. Though I never had issues using a view column on an XPage (using the @ViewIconUrl function), HCL thought it would be worth fixing it.
The part of the code looks to me as it is responsible to compute URLs to resources that are bound to the XPage like Javascript or CSS file resources. I am investigating further to find a simple example.
Personally, when I read the code, I'd go for an additional check whether the string "s" actually contains a "/" before I split it and then access the 2nd element of the resulting array.
The case is filed under CS0307732. The defect is documented here: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0097576
Update 1
With the help of the HCL support I was able to re-create the issue that lead to this fix. Create a blank NSF, import an image to the resources, create an XPage and place this image on the page. The code looks something like this:
<xp:image url="/actn010.gif" id="image1"></xp:image>
Now open the page using the Replica ID in the URL instead of the file path and file name:
https://<yourHost>/<replicaId>/test.xsp
With FP4 or 12 you won't see the image, instead you will see an error 404 in the dev console of your browser.
The same is true for any resource you add to your XPage like a client side Javascript file using the <xp:this.resources> block. Using FP5 now fixes this issue - and breaks something else which I still didn't figure out when this happens.
Update 2
Meanwhile others were provided with a HF, too, which delivered new issues. Sean Cull posted those on his blog.