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
>