Hi,
On Sat, Aug 27, 2016 at 8:42 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> https://java.net/projects/javaserverfaces-spec-public/
> lists/users/archive/2013-03/message/22
> https://issues.apache.org/jira/browse/MYFACES-3797
>
The way the problem was approached previously was to have the converters
and validators still be fully JSF managed artefacts with all their features
and established behaviour and then as bonus "simulate" the CDI injection
into them.
What Manfred did however was to largely shake off the requirements of the
old Converter, and make the new converter fully a CDI bean. This can be
seen here:
https://github.com/jsf-spec/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java#L120
This breaks some of the behaviour that JSF native converters have, such as
the super type/interface match and the variant with the constructor with
the actual type.
With the CDI variant, you ask for a Double converter and get exactly a
Double converter. There's no automatic lookup for a Number converter
anymore. But in return you DO get a fully CDI managed converter and there's
no need to integrate life-cycles or anything. That is "simply' taken out of
the picture, so there are also no deeper integration APIs from CDI needed
here.
For the ResourceHandler, although I haven't looked into it in more detail
yet, I assume it would be an application scoped artefact. If somewhere the
object life-cycle should be managed by JSF then it will then in the CDI
variant not be managed by JSF anymore, we'll not be trying to have JSF
manage it.
This will then change behaviour, most likely. So the CDI version is not
backwards compatible itself, BUT... we of course need to make sure that the
older native behaviour is stil retained and that it's possible to switch
between the two. It goes without saying that with JSF's strict backwards
compatibility requirements we can't just change the behaviour and call it a
day.
Hope this makes it more clear.
Kind regards,
Arjan Tijms
>
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>