FacesConverter LifeCycle and Scope

I'm reposting here as @mnriem asked !

I found that a lot of people (me included) are confused
about the default scope of FacesConverter
or if it is even possible to define a Scope

https://stackoverflow.com/questions/15956072/jsf-converter-scope-when-using-cdi-seam-3-view-scoped

https://stackoverflow.com/questions/4268179/generic-jsf-entity-converter

https://stackoverflow.com/questions/19180457/jsf-custom-converter-life-cyle

https://stackoverflow.com/questions/59457133/application-scoped-bean-for-converter-for-pselectonemenu

Now that we are finally in the CDI world shouldn't be the case to
clarify this point ?

**I think that 'stateless' converters like for example a LongConverter
which is basically something like**

`return isBlank(value) ? null : Long.valueOf(value)`

**should be @ApplicationScoped**

Talking with @arjantijms I discovered that the actual mechanism is very complex:

> It then wraps the bean returned by CDI in a delegating converter instance. This wrapper then delegates to the bean returned by CDI. This wrapper can be state-saved, but since the CDI bean is stored in a transient field it won't save&restore that. Instead, it will only save&restore the converterId or forClass. The restored wrapper will then use the JSF Application instance to ask for a converter with said converterId or forClass (which will go to CDI again, and will do the wrapping again, so we have a double wrapped converter at this point).

If I understand correctly the typical travel search form:

- **city** converted to a jpa entity
- **people** converted to Integer or Long
- **rooms** converted to Integer or Long
- **from** converted to Date
- **to** converted to Date

generates 5 execution of the algorithm to find the appropriate converter
plus 5 CDI creation and injection of the right converter
and create 5 faces converter instances + 5 wrapper instance
every submit:

I think that, at least for basic types, the converters should be one per Application
and the mapping with returned type saved into some data structure during
Faces bootstrap using the actual algorithm

Start with the converter-resolution, CDI wrapping, and state-saving lifecycle described in the issue, then review the linked Stack Overflow cases. Done means reaching a maintainer decision on converter scopes and lifecycle behavior, with the agreed behavior documented or implemented and its basic-type performance implications addressed.

Written by the indexing model from the issue text.