Non-existent view with non-standard mapping incorrectly throws ViewHandlingStrategyNotFoundException instead of returning 404

[BalusC]

Discovered in omnifaces/omnifaces@9d1ebaf

Have an additional mapping on FacesServlet using an URL pattern which does not match Facelets default suffix:

	<servlet-mapping>
		<servlet-name>facesServlet</servlet-name>
		<url-pattern>*.xhtml</url-pattern>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>

Opening non-existent view on an URL pattern which coincidentally matches Facelets default suffix of .xhtml such as /foo.xhtml correctly returns 404.

However, opening non-existent view on an URL pattern which does not match Facelets default suffix of .xhtml such as /foo.jsf incorrectly throws ViewHandlingStrategyNotFoundException instead of returning 404.

com.sun.faces.application.view.ViewHandlingStrategyNotFoundException
	java.base/java.util.Optional.orElseThrow(Optional.java:408)
	com.sun.faces.application.view.ViewHandlingStrategyManager.getStrategy(ViewHandlingStrategyManager.java:57)
	com.sun.faces.application.view.ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(ViewDeclarationLanguageFactoryImpl.java:45)
	com.sun.faces.application.view.MultiViewHandler.getViewDeclarationLanguage(MultiViewHandler.java:407)
	jakarta.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:335)
	jakarta.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:335)
	com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:179)
	com.sun.faces.lifecycle.Phase.doPhase(Phase.java:72)
	com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:95)
	com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:159)
	jakarta.faces.webapp.FacesServlet.executeLifecyle(FacesServlet.java:691)
	jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:449)

It worked fine in Mojarra 4.0.0-M1.

The bug was introduced during 45848de
The ViewHandler#deriveLogicalViewId() is specified to allow returning non-existent view IDs. However during abovementioned work it's converting view ID using MultiViewHandler#convertViewId() which by itself does:

            if (vdl.viewExists(context, convertedViewId)) {
                // RELEASE_PENDING (rlubke,driscoll) cache the lookup
                return convertedViewId;
            }

This check is in hindsight superflous and should be removed. The convertViewId() method is nowhere else used. The ViewHandler#deriveViewId() already does that check by itself.

[arjantijms]

With this change, a TCK test now fails.

/**
* @testName: viewHandlerDeriveLogicalViewIDTest
* 
* @assertion_ids: JSF:JAVADOC:368; JSF:JAVADOC:2533
* 
* @test_Strategy: Validate that we Derive and return the viewId from the
* current request. (with no physical view)
* 
* @since: 2.2
*/
public void viewHandlerDeriveLogicalViewIDTest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

    PrintWriter out = response.getWriter();
    String viewId = "/viewId";
    FacesContext context = getFacesContext();
    ViewHandler vh = getApplication().getViewHandler();
    
    // Get viewId
    String derivedId = vh.deriveLogicalViewId(context, viewId);
    
    if (!viewId.equals(derivedId)) {
     out.println(JSFTestUtil.FAIL + [JSFTestUtil.NL](http://jsftestutil.nl/)
         + "Unexpectecd value from ViewHandler.deriveViewId()" + [JSFTestUtil.NL](http://jsftestutil.nl/)
         + "Execpted: " + viewId + [JSFTestUtil.NL](http://jsftestutil.nl/) + "Received: " + derivedId);
    } else {
        out.println(JSFTestUtil.PASS);
    }
}// End viewHandlerDeriveLogicalViewIDTest

Note that the referenced assertion_ids are seemingly bogus.

[arjantijms]

CC @BalusC