jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: Features from JSF Managed Beans not present in CDI

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Thu, 15 Dec 2016 17:36:22 -0500

Hi

Looks like SystemEventListener instances are injectable since JSF 2.2, so no
additional work needs to be done here.

regards,

Leonardo Uribe

2016-12-15 17:16 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:

> Hi
>
> Thanks guys for the feedback. It helps a lot.
>
> In this point I think it sounds better to explore how to make JSF
> listeners CDI injectable,
> so you can write a listener to PostConstructApplicationEvent
> and PreDestroyApplicationEvent
> that can be injected with CDI beans.
>
> What I mean is the important thing is provide to developers a way to
> migrate this use case
> in a consistent way.
>
> regards,
>
> Leonardo Uribe
>
>
> 2016-12-15 13:20 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
>
>> Executive Summary:
>>
>> Ed pushes back on spec support for @Eager, a new CDI Scope for
>> Application, and changes to the init time FacesContext.
>>
>> Details in line.
>>
>> >>>>> On Tue, 13 Dec 2016 18:19:24 -0500, Leonardo Uribe <
>> leonardo.uribe_at_irian.at> said:
>>
>> LU> I'm looking the changes done to improve the integration with CDI and
>> LU> I have two questions related to things that are present in JSF
>> LU> managed beans and not in CDI: (this is important for people using
>> LU> JSF managed beans that plans to move to CDI)
>>
>> LU> - Is there any plans to include an @Eager annotation or something
>> LU> similar in order to provide the same behavior for
>> LU> @ManagedBean(eager="true")?
>>
>> >>>>> On Wed, 14 Dec 2016 18:56:00 +0100, arjan tijms <
>> arjan.tijms_at_gmail.com> said:
>>
>> AT> This feature is largely provided by CDI natively, namely via the
>> @Observes
>>
>> AT> There's also a CDI issue for this specifically here:
>>
>> AT> Going beyond the spec, there's third party support for eagerly
>>
>> Ok, three ways for @Eager. Nice. No need for more spec work there.
>>
>> >>>>> On Thu, 15 Dec 2016 00:39:01 -0500, Leonardo Uribe <
>> leonardo.uribe_at_irian.at> said:
>>
>> LU> I'm afraid these solutions are not good enough.
>>
>> That is a corner case we need to live with at this point. Moving from
>> Managed Beans to CDI was never intended to be 100% feature-for-feature
>> compatible. There is a shift in mental model as well, which provides
>> for different ways of doing things. This is one of them.
>>
>> LU> This is a migration problem. If the EG is serious about deprecate
>> LU> managed beans,
>>
>> I want to remind everyone that we are not removing managed beans in this
>> release, we are marking them @Deprecated, after many years of warning.
>>
>>
>> LU> - Is there any plans to include something similar to
>> LU> @ManagedProperty(value="#{mybean}"), or we will rely on what @Inject
>> LU> already provides?
>>
>> AT> There's a direct CDI replacement for that provided by JSF 2.3. It's
>> AT> in the javax.faces.annotation package. See
>> AT> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1418
>>
>> Again, very nice.
>>
>> [...Leonardo brings up some init time FacesContext issues...]
>>
>> >>>>> On Thu, 15 Dec 2016 17:47:07 +0100, arjan tijms <
>> arjan.tijms_at_gmail.com> said:
>>
>> AT> I have to say that the "fake/startup" FacesContext has been some
>> source of
>> AT> issues. In hindsight, perhaps it should not have been there in the
>> first
>> AT> place.
>>
>> Yes, this is true. If CDI were present and usable when we needed it, we
>> would not have gone down that route.
>>
>> AT> The other is that someone puts in the work to create such producer
>> now. The
>> AT> time we have left is short though, and the available resources likely
>> low.
>> AT> If you'd like to give it a try though, please do. If you can't finish
>> the
>> AT> work before the spec is final you could perhaps use it as a MyFaces
>> AT> specific feature and then we put it in the spec next time.
>>
>> Yes, I agree, it would take a lot of work to add it to the spec at this
>> stage, but if someone presents me with a completely done, implemented
>> and specified solution that is hid behind the existing CDI 2.3 switch
>> and off by default, I would consider it, but it is a very very high
>> bar. On balance, I strongly advise against it.
>>
>> As Arjan pointed out, this is a perfectly good usecase for Omnifaces,
>> and it could be impl portable that way as well.
>>
>> >>>>> On Thu, 15 Dec 2016 12:22:56 -0500, Leonardo Uribe <
>> leonardo.uribe_at_irian.at> said:
>>
>> LU> It is very easy to make a new CDI scope, because in JSF we have
>> LU> already made other scopes, so it is just copy/paste. It would take
>> LU> only hours to make the scope, once we have defined the annotations
>> LU> to include. I created a custom @FacesScoped annotation in that time,
>> LU> so I have no doubts.
>>
>> LU> In JSF there are two events: PostConstructApplicationEvent and
>> LU> PreDestroyApplicationEvent, so I guess an scope can be created over
>> LU> these two events.
>>
>> LU> I can't touch Mojarra code, but I can give it a try in MyFaces and
>> LU> commit the code there, and then tell you guys to do the magic in
>> LU> Mojarra. I think with about two months there is plenty of time to do
>> LU> it.
>>
>> Presenting us with a MyFaces-only solution doesn't meet the above high
>> bar. Before you write any MyFaces code, if you want any chance to have
>> it in 2.3, I strongly recommend you find a partner to produce the
>> Mojarra code at the same time. Otherwise, I suggest you contribute it
>> to OmniFaces.
>>
>> >>>>> On Thu, 15 Dec 2016 18:38:50 +0100, arjan tijms <
>> arjan.tijms_at_gmail.com> said:
>>
>> AT> I agree, it's relatively easy to create a basic scope. But make no
>> mistake,
>> AT> not every scope is basic ;) We worked on e.g. an @Pooled scope before
>> and
>> AT> that was far from trivial to say the least.
>>
>> AT> I personally think a third(!) @ApplicationScoped would be really
>> confusing.
>> AT> We already have a pure JSF one, a pure CDI one, and then also a
>> CDI-JSF
>> AT> hybrid? I'm not sure about that.
>>
>> AT> What could be an easier and more clear option though is to throw 2
>> new CDI
>> AT> events, respectively at the moment the startup FacesContext would
>> become
>> AT> available, and just before it would be destroyed. These two events
>> would
>> AT> align exactly with the moment the JSF runtime now calls the
>> @PostConstruct
>> AT> respectively @PreDestroy in the JSF @ApplicationScoped.
>>
>> Good points, and the fact that you are making them indicates this is
>> certainly not as simple as stated above. More reason to do it outside
>> of the spec for now.
>>
>>
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | 36 business days until DevNexus 2017
>> | 61 business days until JavaLand 2017
>>
>
>