Hi,
For the ordering problem, I guess a CDI extension could be used, that
converts the JSF instantes info managed beans for further wrapping.
The scoping problem looks more difficult. The "simple" solution would be,
again, to create an extension that validates that all the injected
dependencies are from the right scopes and fail the deployment otherwise.
That requirement could be relaxed in the future.
Maybe this is worth talking to the CDI EG. Integration with "legacy"
(non-CDI) apps in an important concern.
Regards,
Guillermo González de Agüero.
On Sat, Aug 27, 2016 at 8:42 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> 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(ResourceV
>> iewHandler.class);
>>
>> // JSF wraps with its specific ordering
>> ResourceViewHandlerWrapper wrapper = new ResourceViewHandlerWrappe(cdiD
>> ecorated):
>>
>>
>>>
>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>