Bauke Scholtz

> Why do we still need a Servlet Filter? For non-Faces requests. > Can't we change the core Faces ExceptionHandler to do at least the same work of OmniFaces FacesExceptionFilter...

It won't have access to FacesContext nor be able to handle Faces Ajax exceptions. These by default don't throw any exception that a filter or error page servlet can catch.

> For ajax we could rethrow it inside the Default JSF ExceptionHandler You can throw it but an error page servlet/filter running outside FacesContext won't be able to render a...

Summarized: it should be sufficient to have: - web.xml for error page config per exception type (and a default error page!) - FullAjaxExceptionHandler to deal with exceptions thrown during Faces...

Responded over there :+1:

Summarized: 1. Configuration is indeed a pain point when you want to cover any exception possible (non-Faces, Faces Ajax, Faces non-Ajax). Ideally it should be able to automatically register/activate `FacesExceptionFilter`...

It's indeed in EL. See also https://balusc.omnifaces.org/2020/11/using-java-14-records-in-jsf-via-eclipse.html

Initial report was confusing because `SelectItem` doesn't have a `key` property. After drilling down into PrimeFaces issue and the source code of the `TestView` bean in the reproducer attached over...

Hmm .. https://jakarta.ee/specifications/faces/4.0/vdldoc/f/selectitems the `value` attribute says this: > The member elements may be instances of SelectItem or any Java Object. and this: > The attributes on lines 3 through...

No other occurrences found in the spec. I'd say, fix it in the impl. I do however propose to simply remove the phrase "The attributes on lines 3 through 9,...