dev@javaserverfaces.java.net

RE: JAVASERVERFACES-3939

From: Xavier Dury <kalgon_at_hotmail.com>
Date: Fri, 15 Jan 2016 16:31:40 +0100

Hi,

my problem is not the clarity of the message itself.

If you look at ScopedAttributeElResolver, you will find this method:

public void setValue(ELContext context, Object base, Object property, Object val) throws ELException {
        if (base != null) {
                return;
        }
        if (property == null) {
                String message = MessageUtils.getExceptionMessageString(MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID, "base and property"); // ?????
                throw new PropertyNotFoundException(message);
        }

        context.setPropertyResolved(true);

        String attribute = (String) property;
        FacesContext facesContext = (FacesContext) context.getContext(FacesContext.class);
        ExternalContext ec = facesContext.getExternalContext();
        if ((ec.getRequestMap().get(attribute)) != null) {
                ec.getRequestMap().put(attribute, val);
        } else if ((facesContext.getViewRoot()) != null && (facesContext.getViewRoot().getViewMap().get(attribute)) != null) {
                facesContext.getViewRoot().getViewMap().put(attribute, val);
        } else if ((ec.getSessionMap().get(attribute)) != null) {
                ec.getSessionMap().put(attribute, val);
        } else if ((ec.getApplicationMap().get(attribute)) != null) {
                ec.getApplicationMap().put(attribute, val);
        } else {
                // if the property doesn't exist in any of the scopes, put it in
                // request scope.
                ec.getRequestMap().put(attribute, val);
        }
}

This method will try to evaluate the property in each scope and if, for that scope, the parameter is not null, it will replace it in that scope.

So, it will check if the parameter is found in the request scope -> nope
Then the viewScope -> nope but by checking if it is there, it will call getViewMap() and create the viewMap leading to the warning. (getViewMap() or getViewMap(true) creates the viewMap if none exists)
Then the sessionScope -> nope
Then the applicationScope -> nope
Then, by default, store it in the requestScope as nothing was found in any scope.

While checking if the value is present in the viewScope, nothing is done to prevent to the creation of that scope if the view is transient and that leads to the warning.

Xavier
________________________________
> Date: Fri, 15 Jan 2016 16:13:53 +0100
> Subject: Re: JAVASERVERFACES-3939
> From: arjan.tijms_at_gmail.com
> To: dev_at_javaserverfaces.java.net
>
> I agree that the message is not super clear, but the beans will not
> *actually* be placed in request scope. They will still reside in the
> session, but they merely act as-if they were request scoped.
>
> In other words, because there's no view-id written to the page, the
> view scoped bean residing in the session can't be found anymore after a
> postback (since that id is normally used to retrieve it).
>
> Since stateless views would be expected to use GET based links more
> often than non-stateless ones, you run the risk of polluting the
> session with a lot of unused view scoped beans. Therefor with stateless
> views and the current version of the view scope as it ships with JSF
> 2.2, it's far better to NOT use the view scope.
>
> The message, more or less, says this, but indeed it's not super clear.
>
>
>
>
>
>
>
>
> On Fri, Jan 15, 2016 at 4:01 PM, Kito Mann
> <kito.mann_at_virtua.com<mailto:kito.mann_at_virtua.com>> wrote:
> Xavier is right about the message, too; it's confusing. At the very
> least, it should say "View [xyz] has been marked as stateless; any
> @ViewScoped beans will be placed in request scope."
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training
> and consulting
> Virtua, Inc. | virtua.tech<http://virtua.tech>
> JSFCentral.com<http://JSFCentral.com> | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast:
> http://<http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com<http://ww.enterprisejavanews.com>
>
>
> On Thu, Jan 14, 2016 at 2:32 PM, Lenny Primak
> <lprimak_at_hope.nyc.ny.us<mailto:lprimak_at_hope.nyc.ny.us>> wrote:
> This issue and solutino seem pretty reasonable (and easy!) to me.
>
>> On Jan 14, 2016, at 10:19 AM,
> kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com> wrote:
>>
>> Hi,
>>
>> Could some administator re-evaluate JAVASERVERFACES-3939?
>>
>> I really think it has been closed without understanding what the
>> problem was.
>>
>> I've added everything I could to make it clear what the problem was but
>> as the issue is closed, I'm afraid nobody will even take a look at it.
>>
>> Thanks,
>>
>> Xavier
>>
>
>
>