[jsr-314-open-mirror] [jsr-314-open] Should the ViewDeclarationLanguage be responsible to indicate if a viewId can be created?

Hi The current algorithm to check if a view with a specific viewId does not allow to add or extends a new ViewDeclarationLanguage using a new prefix/extension. This issue is related to https://issues.apache.org/jira/browse/MYFACES-2628 Facelets ResourceSolver can't work and https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567 The problem resides on a "hidden" requeriment for Restore View Phase algorithm, that is ignored silently. On mojarra, this is the code on MultiViewHandler.getViewDeclarationLanguage: public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext context, String viewId) { String actualViewId = derivePhysicalViewId(context, viewId, false); return vdlFactory.getViewDeclarationLanguage(actualViewId); } Now on myfaces is this: @Override public ViewDeclarationLanguage getViewDeclarationLanguage( FacesContext context, String viewId) { // return a suitable ViewDeclarationLanguage implementation for the given viewId return _vdlFactory.getViewDeclarationLanguage(viewId); } The difference is subtle, but very, very important. This method is called from many locations, but only once (from RestoreViewPhase) it is passed the "raw" viewId. To "derive" the physical viewId it is required to know if prefix or suffix mapping is used and if suffix mapping is used, try to check if a view "resource" exists or not with different derived ids with the extensions configured ".xhtml .jsp". javax.faces.view.facelets.ResourceResolver documentation says this: "... Provide a hook to decorate or override the way that Facelets loads template files. A default implementation must be provided that satisfies the requirements for loading templates as in Pre-JSF 2.0 Facelets ..." So, in theory it is possible to override ResourceResolver interface and serve resources from a different location. But the algorithm in MultiViewHandler.derivePhysicalViewId does not take into account this interface, so it try to check if the view "resource" exists on the same location and fails. The solution proposed is add a method on ViewHandler, ViewDeclarationLanguageFactory and ViewDeclarationLanguage called: public boolean existsViewId(String viewId) So the VDL can indicate if a viewId exists or not. In this way, on Facelets VDL we can check if a viewId exists using the ResourceResolver instance. It is curious that ViewDeclarationFactory implementation has some methods that indicate if a vdl can handle a viewId or not (it is not the same, but similar). I'm not done too much work on this issue, but it could be good to take a look at this one. It could be good to open an issue on the spec for this one too (if no objections I'll open an issue for this one, but better to ask first). Suggestions are welcome. regards, Leonardo Uribe