Hi
What I mean is JSF should create some base instances or default
implementations and then let CDI do the wrapping, not the opposite.
Take a look at this thread:
https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2013-03/message/22
https://issues.apache.org/jira/browse/MYFACES-3797
regards,
Leonardo Uribe
2016-08-27 13:26 GMT-05:00 Guillermo González de Agüero <
z06.guillermo_at_gmail.com>:
> Hi,
>
> Comments inline.
>
> On Sat, Aug 27, 2016 at 7:49 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> 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.
>>
> But my idea is to do this apart from faces-config.xml. CDI orders
> decorators with the @Priority annotation, so this could take effect before
> or after *all* faces-config.xml related changes.
>
> So, for example, we could have:
>
> // CDI instantiates its beans
> ResourceViewHandler cdiDecorated = CDI.current().select(
> ResourceViewHandler.class);
>
> // JSF wraps with its specific ordering
> ResourceViewHandlerWrapper wrapper = new ResourceViewHandlerWrappe(
> cdiDecorated):
>
>
>>
>> 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).
>>
> Just to understand it, what kind of problems do you refer? There was a
> discussion about adding support for unmanaging managed beans for CDI 2.0 (
> https://issues.jboss.org/browse/CDI-561). Could that help here?
>
>
>>
>> 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
>>>>>>
>>>>>
>>>>>
>>>
>>
>