FYI, adding adding *.xhtml to the default mappings affects existing requirements of the JSF Portlet Bridge. Specifically, the requirements for ExternalContext.encodeActionURL(String), getRequestPathInfo(), and getRequestServletPath() in section 6.1.3.1 titled "Methods that deviate from Faces 1.2 Javadoc”
> On Oct 22, 2014, at 5:51 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
>
>>>>>> On Wed, 22 Oct 2014 00:03:31 +0200, arjan tijms <arjan.tijms_at_gmail.com> said:
>
> [...]
>
> AT> An optimal solution going forward and absolutely trivial to implement
> AT> is just adding *.xhtml to the default mappings. However, this may have
> AT> backwards compatibility issues and has therefor been rejected
> before.
>
> Indeed.
>
> AT> Another solution is to use the recently introduced switch, that uses a
> AT> 2.3 faces-config and/or 4.0 web.xml for possibly incompatible EL
> AT> resolving behavior, to switch between having *.xhtml as a default
> AT> mapping or not. Meaning a 2.3 faces-config.xml causes a mapping on
> AT> *.xhtml by default, any lower versioned or no faces-config keeps the
> AT> current mappings.
>
> I can see this, and it would be easy to implement in the
> ServletContainerInitializer impl. In Mojarra this is FacesInitializer.
> Can someone code up a patch for this?
>
> AT> Yet another solution, that incidentally also ties in with the
> AT> extensionless URL mappings that were discussed on this list a while
> AT> back, is to have a dedicated folder from which views are loaded.
>
> AT> This is not entirely unlike the dedicated folders for contracts and
> AT> composites that already exist today. Views in that folder would be by
> AT> definition JSF views, so the runtime can safely map them, with or
> AT> without extension. A while back I created
> AT> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1099 for this
> AT> and implemented it in OmniFaces.
>
> That sounds good too.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 12 work days til Devoxx 2014