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