users@javaserverfaces-spec-public.java.net

[jsr372-experts mirror] Re: CDI decorator support for FacesWrapper subclasses

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Sat, 27 Aug 2016 12:49:26 -0500

Hi

The problem is JSF requires to control object instantiation in a specific
ordering. There is an algorithm that "sort" faces-config.xml files and
related configuration.

In my understanding, CDI requires to override the object instantiation.
That means each object is instantiated by CDI from the beginning.

So, the current strategy to deal with this problem is try to "workaround"
that limitation, but that is not easy because the object lifecycle should
be managed by JSF, not by CDI, and it is usual to find cases where the
object needs to be destroyed, but CDI doesn't help (at least in CDI 1.0).

regards,

Leonardo Uribe


2016-08-27 12:29 GMT-05:00 Guillermo González de Agüero <
z06.guillermo_at_gmail.com>:

> 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
>>>>
>>>
>>>
>