Hi Arjan,
Thanks as always for you elaborate clarifications! Glad to see the new
config annotation will take care of all this stuff.
Regarding the converters problem, while I fully respect and really
appreciate the work done by this EG, as a JSF user, I think it needs to
provide a better CDI integration to be seen as a "modern" and up-to-date
framework. JSF is already well suited for day to day job with libraries
like OmniFaces and PrimeFaces, but for more advanced stuff, I'd like to be
able to use decorators instead of wrapper classes, CDI events instead of
creating phase listeners, alternatives instead of factories defined in an
XML, out-of-the-box injection on all artifacts, etc. Sure we can live
without all of that (what we have now does the same job, just more
verbose), but IMO these kind of things would be a boost for JSF, and would
benefit from better tooling support.
Backward compatibility is the problem here. But I'd personally go for new
interfaces/mechanisms if they are needed, that could perfectly live along
the current ones in many cases (think of @ManagedBean that's going to be
deprecated now). rather than trying to maintain a totally compatible
behavior with the current ones. For example: you could define new CDI
events for the phase listeners. That events could be fired after the
"traditional" ones. The current mehanism works well, but I'd certainly
prefer just to annotate a method with @Observes, and I would gain Weld
Probe statistics for development[1].
But a more realistic approach for now could be just to create new
annotations to define the things that are now to be done in
faces-config.xml. Annotations could be provided for registering taglib
functions (annotating static methods), all kind of wrappers, FacesContext
implementations (it would be checked at deployment time that no more than
one class is annotated for this), EL resolvers, etc. If that kind of work
was already planned for your new configuration mechanism, then I think it
will suffice for now. But still, I think some research has to be done for a
better CDI integration in future versions (Java EE 9 and JSF 3.0?).
Regards,
Guillermo González de Agüero.
[1]
http://blog.eisele.net/2015/02/playing-with-weld-probe-see-all-of-your.html
On Sat, Sep 24, 2016 at 5:08 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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.
>>
>
>