JSF 2.3: “Array index out of range” when rendering a form with Url containing ''&&"

Question

Given a url with params such that:

page.xhtml?param1=value&&param2=value

It appears that after submitting a form on that page, the following exception and stack trace occurs:

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
    at org.apache.myfaces.context.servlet.ServletExternalContextImpl.encodeURL(ServletExternalContextImpl.java:906)
    at org.apache.myfaces.context.servlet.ServletExternalContextImpl.encodeActionURL(ServletExternalContextImpl.java:364)
    at javax.faces.context.ExternalContextWrapper.encodeActionURL(ExternalContextWrapper.java:80)
    at org.apache.myfaces.shared.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:88)
    at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
    at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
    at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
    at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
    at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1897)

It appears that this will happen when the form is being re-rendered.

Using ajax to narrow what is being re-rendered allows me to side step the issue.

With that said, I'm wondering if there are more options to fixing this issue?

Using IBM's Liberty 18.0.0.3, IBM's JSF 2.3 [1.0.0]

Answer 1

That version of WebSphere Liberty is almost 3 years old, so I would first recommend moving up to a recent version of WebSphere Liberty (or Open Liberty ) and checking if the issue has since been resolved.

With Liberty's zero migration architecture, the move to the latest version should be pretty seamless.... and not only will you get ~3 years worth of bug & security fixes but also performance and development enhancements.

Answer 2

It appears this issue is unique to my project's configurations. After some selective removals and additions it was discovered that a view-handler responsible for re-attaching request params back onto the url was the culprit.

The param string

param1=value&&param2=value

Would be reattached as

=&param1=value&param2=value

Which in turn caused the encoding exception.

Thank you and Apologies.