Hi Guillermo,
The current situation is indeed not optimal, but that's partially because
different methods to switch were investigated and experimented with
(remember, it are milestones ;)). At some point co-spec lead Manfred Riem
stopped working on this, which left some parts of the code using the
faces-config version, and some parts using the context parameter. In a
select few cases this even leads to plain faulty behaviour and feedback
(since both of the settings are sort of conflicting).
However, I already started working on a single switch to enable/disable all
JSF 2.3 features, and to remove the switches in the code that were about to
be removed back then but weren't. You can find this here:
https://github.com/jsf-spec/mojarra/commits/config
Unfortunately I haven't had the time to work on that since. Documentation
of what has been done in 2.3 till so far (see
http://arjan-tijms.omnifaces.org/p/jsf-23.html) and work for JSR 375, as
well as my normal day job took pretty much all of my free time and energy.
I will continue with that hopefully before long. That will at least take
care of the conflicting settings now, and may potentially solve some very
subtle incompatibility issues with CDI (with the new setting, the new CDI
beans will not even be registered, as opposed to the beans checking for the
setting as happens now).
The managed attribute, I know... it's troublesome, but also necessary.
Manfred used this one as a binding attribute of a qualifier that CDI needs
to do the lookup. CDI can't (shouldn't) lookup the old style converters,
since the behaviour has radically changed. E.g. the trick with the
constructor with a parameter doesn't work anymore, plus converters are only
looked-up now for their exact type.
I.e. if you had a Double in your application and have a Number converter,
the old style Converters will find that Number converter in absence of a
better matching one (there's a very elaborate algorithm specified to find
matches for super classes and interfaces + super interfaces).
In the CDI version this is simplified to the extreme. To convert a Double
you need a Double converter. Nothing more, nothing less. Because this is
such an extreme change, and not just "making injection possible in
converters", we could even have opted for a completely new interface and
deprecate the old one. Not really sure about that yet, but it's still an
option perhaps.
Kind regards,
Arjan Tijms
On Sat, Sep 24, 2016 at 4:26 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> Hi,
>
> JSF 2.3 will bring (up to now) at least 3 new great features that will
> require manual activation: WebSocket, class level validation and CDI
> managed converters/validators/behaviors.
>
> To be able to use that, a user will need the following context params:
>
> <!-- WebSocket -->
> <context-param>
> <param-name>javax.faces.ENABLE_CDI_RESOLVER_CHAIN</param-name>
> <param-value>true</param-value>
> </context-param>
> <context-param>
> <param-name>javax.faces.ENABLE_WEBSOCKET_ENDPOINT</param-name>
> <param-value>true</param-value>
> </context-param>
> <!-- Class level validation -->
> <context-param>
> <param-name>javax.faces.validator.ENABLE_VALIDATE_WHOLE_
> BEAN</param-name>
> <param-value>true</param-value>
> </context-param>
>
> Moreover, the new attribute "managed" needs to be set to true in *all*
> converters, validators and behaviors in order for them to be injectable.
> Not sure if this option is supported for xml declared components.
>
> While I can (to a point) understand that these features are disabled by
> default, to ensure backward compatibility, I just see it quite tedious to
> do all that just to use the new features of an udpated library.
>
> I propose to add a new "javax.faces.MAINTAIN_JSF22_STRICT_COMPATIBILITY",
> that when disabled:
> - Enables CDI resolver chain
> - ¿Enables the WebSocket endpoint?
> - Enables class level validation (not sure why this can't me enabled by
> default anywyay)
> - Makes mentioned artifact CDI managed unless contrary stated (annotation
> would take precedence over the context param here). The scope of this
> setting should be discussed: should it apply only to the WAR where it's
> defined, or should it apply also to lib jars? This could be solved by using
> faces-config.xml instead of a context param to enable new features.
>
> To go one step further, this param could be disabled by default for
> applications containing a 2.3 faces-config.xml file.
>
> What do you think?
>
>
> Regards,
>
> Guillermo González de Agüero.
>