Before you update to FP5 of 11.0.1

Monday, March 28, 2022 at 2:29 PM UTC

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.






Latest comments to this post

64bit wrote on 26.04.2022, 05:47

HCL has provided hotfix 1101FP5HF10_W64.exe which solved the problem.

 Link to this comment
Martin Davies wrote on 29.03.2022, 10:12

Thanks for posting this Oliver - very helpful.

We have the same issue and have opened case CS0307100 with HCL. I've referenced your case on our ticket.

Martin

 Link to this comment
64bit wrote on 29.03.2022, 06:17

I'm encountering the same error right after upgraded from Domino 11.0.1 FP4 to FP5.

I have created case referring to your case as well.

 Link to this comment

Leave a comment right here