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