Hi
In my personal opinion, I guess the api we have in CDI right now is
insufficient to achieve a deeper integration between JSF and CDI. But
that's my opinion, and I have not checked CDI 2.0 fully to see how far can
we go (that's part of JSF 2.3). So, at this point I can only tell you the
problems we have had in the past.
regards,
Leonardo Uribe
2016-08-27 14:03 GMT-05:00 Guillermo González de Agüero <
z06.guillermo_at_gmail.com>:
> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>