Hi,
For a relatively new open source project (say OmniFaces, but also
OmniServe), it's perhaps not that much work.
With a code base as old as Mojarra (going since ~2003) almost nothing is
easy, unfortunately. Add to that the fact that if something goes into a
spec it can't easily be taken out anymore (i.e. make one mistake and you
have to support it for almost ever).
If we had anyone working on Mojarra at least say a full day per week, it
would likely already have been done. Currently it's more like doing some
coding during commutes and in the rare hours of free time in between.
Your idea is perfectly in line though with what we, including co sped lead
Manfred, had been planning for. And indeed, for the current CDI
replacements we have put the context param in place.
One very practical problem though is that CDI beans here are enabled in a
CDI extension, and CDI extensions can't read a context param defined in
web.xml :(
Brian Leathem (who's actually a JSF 2.3 EG member, albeit a very quiet one)
logged an issue for this nearly 5 years ago:
https://issues.jboss.org/browse/CDI-152 I'll make a mental note to make a
comment there at its 5th anniversary.
CDI extensions can read annotated classes, so I started the annotated
config work here:
https://github.com/jsf-spec/mojarra/tree/config I hope to
finish that before long, after which we still have to finish the CDI beans
for implicit variables and the extensionless URL feature, and maybe
somewhere before or after that find time to convert more JSF artefacts to
CDI based ones.
Kind regards,
Arjan Tijms
On Sat, Aug 27, 2016 at 7:29 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> Hi,
>
> I'm of course not the most appropiate guy to asses that, but I don't
> imagine that as being that much work, depending on the level of integration
> we want to get.
>
> My idea was basically: keep the current behaviour as it is now + convert
> those artifact into beans and let the user decorate them. That new
> behaviour would only be enabled if a new context param
> javax.faces.ENABLE_DEEP_CDI_INTEGRATION is set to true (false being the
> default value), so compatibility is preserved.
>
> I suppose I'm missing something?
>
> Btw: didn't know about OmniServe. I'll take a look at it.
>
>
> Regards,
>
> Guillermo González de Agüero
>
> On Sat, Aug 27, 2016 at 5:41 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> Something like that would be something we'd eventually want to end up
>> with I guess, but it requires a refactoring and compatibility change beyond
>> what we can currently sustain.
>>
>> A ground up attempt capable of basically what you ask was started here
>> btw:
>>
>> https://github.com/omnifaces/omniserve
>>
>> Doing the same for JSF / Mojarra would likely require a lot of resources,
>> if only to make sure we stay absolutely compatible. The cdi alignment story
>> only worked on converters, validators and EL resolution until know and that
>> already took a lot of time and is by far not ready.
>>
>> Kind regards,
>> Arjan Tijms
>>
>> On Saturday, August 27, 2016, Guillermo González de Agüero <
>> z06.guillermo_at_gmail.com> wrote:
>>
>>> Another benefit I forgot: with that kind of CDI integration we'd also
>>> get an improved debugging experience, thaks to tools like Weld Probe [1]. A
>>> common JSF application already has a component library (e.g. PrimeFaces)
>>> and OmniFaces present. At the moment it is difficult to get an overview of
>>> the "decorated" artifacts, and that could be handy when the user wants to
>>> add another wrapping layer.
>>>
>>>
>>> Regards,
>>>
>>> Guillermo González de Agüero
>>>
>>> [1] https://developer.jboss.org/people/mkouba/blog/2015/02/05/we
>>> ld-probe--inspect-your-cdi-application-at-runtime
>>>
>>> On Sat, Aug 27, 2016 at 4:19 PM, Guillermo González de Agüero <
>>> z06.guillermo_at_gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> As part of the CDI alignment effort for JSF 2.3, I'd like to propose
>>>> another enhancement.
>>>>
>>>> Currently, there are a lot of artifacts that can be wrapped (decorated)
>>>> by extending a FacesWrapper implementation and registering them at
>>>> faces-config.xml [1].
>>>>
>>>> I'd like to be able to just use CDI decorators for this, like:
>>>>
>>>> @Priority(1000)
>>>> @Decorator
>>>> public abstract MyCustomResourceHandler extends ResourceHandler {
>>>>
>>>> @Inject
>>>> @Delegate
>>>> private ResourceHandler rh;
>>>>
>>>> @Override
>>>> public Resource createResource(String resource) {
>>>> // ..
>>>> }
>>>> }
>>>>
>>>> The only problem is that CDI requires the decorated artifact to be an
>>>> interface instead of a class. So to achieve this. So methods would need to
>>>> be extracted to new interfaces.
>>>>
>>>> The end user benefits would be a simplified and more standard way to
>>>> decorate artifacts and less need for the faces-config.xml.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Guillermo González de Agüero.
>>>>
>>>> [1] https://javaserverfaces.java.net/docs/2.2/javadocs/javax/fac
>>>> es/FacesWrapper.html
>>>>
>>>
>>>
>