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

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

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Thu, 15 Dec 2016 18:38:50 +0100

Hi,

I agree, it's relatively easy to create a basic scope. But make no mistake,
not every scope is basic ;) We worked on e.g. an @Pooled scope before and
that was far from trivial to say the least.

I personally think a third(!) @ApplicationScoped would be really confusing.
We already have a pure JSF one, a pure CDI one, and then also a CDI-JSF
hybrid? I'm not sure about that.

What could be an easier and more clear option though is to throw 2 new CDI
events, respectively at the moment the startup FacesContext would become
available, and just before it would be destroyed. These two events would
align exactly with the moment the JSF runtime now calls the @PostConstruct
respectively @PreDestroy in the JSF @ApplicationScoped.

Thoughts?

Kind regards,
Arjan Tijms







On Thu, Dec 15, 2016 at 6:22 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:

> Hi
>
> It is very easy to make a new CDI scope, because in JSF we have already
> made
> other scopes, so it is just copy/paste. It would take only hours to make
> the scope,
> once we have defined the annotations to include. I created a custom
> @FacesScoped annotation in that time, so I have no doubts.
>
> In JSF there are two events: PostConstructApplicationEvent and
> PreDestroyApplicationEvent, so I guess an scope can be created over these
> two
> events.
>
> I can't touch Mojarra code, but I can give it a try in MyFaces and commit
> the code
> there, and then tell you guys to do the magic in Mojarra. I think with
> about two
> months there is plenty of time to do it.
>
> regards,
>
> Leonardo Uribe
>
> 2016-12-15 11:47 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>
>> Hi,
>>
>> On Thu, Dec 15, 2016 at 6:39 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>> wrote:
>>
>>> In other words, JSF Managed Bean Application Scope ensures there is a
>>> valid FacesContext instace on @PostConstruct and @PreDestroy. CDI
>>> Application Scope does not ensures that, so code that rely on get a
>>> FacesContext instance at startup will no longer work if managed beans
>>> are deprecated, or at least this part of the code can't be migrated
>>> properly to CDI.
>>>
>>
>> True, true, so luckily the CDI application scope doesn't automatically
>> overtakes the existing JSF one.
>>
>> I have to say that the "fake/startup" FacesContext has been some source
>> of issues. In hindsight, perhaps it should not have been there in the first
>> place. If this view is supported by the other EG members it may be a good
>> thing that this will not be available.
>>
>> There's a couple of solutions here though. One is that after the spec is
>> released, third party libraries like OmniFaces fill this void by providing
>> a producer for this special startup FacesContext. There's a precedence for
>> that, as in previous steps to move to CDI, the JSF spec also omitted some
>> features (like e.g. a CDI @ViewScoped).
>>
>> The other is that someone puts in the work to create such producer now.
>> The time we have left is short though, and the available resources likely
>> low. If you'd like to give it a try though, please do. If you can't finish
>> the work before the spec is final you could perhaps use it as a MyFaces
>> specific feature and then we put it in the spec next time.
>>
>>
>>> AT>> There's a direct CDI replacement for that provided by JSF 2.3. It's
>>> in
>>> AT>> the javax.faces.annotation package.
>>>
>>> Ok, it is not yet in the javadoc. Thanks for the link, that gives me an
>>> idea about how it will work.
>>>
>>
>> The JavaDoc should be there, it's:
>>
>> /**
>> * <p class="changed_added_2_3">The presence of this annotation (along
>> * with {_at_code @Inject}) on a field of any type causes the value returned
>> from
>> * evaluating an expression language expression to be
>> * injected as the value of that field. </p>
>> */
>>
>> @Qualifier
>> @Target(FIELD)
>> @Retention(RUNTIME)
>> public @interface ManagedProperty {
>>
>> /**
>> * <p class="changed_added_2_3">Taken to be the value that is
>> injected into
>> * the field. </p>
>> *
>> * @return the value.
>> */
>> @Nonbinding
>> String value();
>>
>> ...
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2016-12-14 12:56 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>>>
>>>> Hi Leo,
>>>>
>>>> On Wed, Dec 14, 2016 at 12:19 AM, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> wrote:
>>>>
>>>>> - Is there any plans to include an @Eager annotation or something
>>>>> similar in order to provide the same behavior for
>>>>> @ManagedBean(eager="true")?
>>>>>
>>>>
>>>> This feature is largely provided by CDI natively, namely via
>>>> the @Observes @Initialized(ApplicationScoped.class) construct. See
>>>> Romain's blog post about this here: https://rmannibucau.word
>>>> press.com/2015/03/10/cdi-and-startup
>>>>
>>>> There's also a CDI issue for this specifically here:
>>>> https://issues.jboss.org/browse/CDI-473
>>>>
>>>> Going beyond the spec, there's third party support for eagerly
>>>> instantiating CDI beans via OmniFaces: http://showcase.omn
>>>> ifaces.org/cdi/Eager
>>>>
>>>>
>>>>
>>>>> - Is there any plans to include something similar to
>>>>> @ManagedProperty(value="#{mybean}"), or we will rely on what @Inject
>>>>> already provides?
>>>>>
>>>>
>>>> There's a direct CDI replacement for that provided by JSF 2.3. It's in
>>>> the javax.faces.annotation package. See http://arjan-tijm
>>>> s.omnifaces.org/p/jsf-23.html#1418
>>>>
>>>> Hope this cleared things up.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>
>>>>
>>>
>>
>