dev@javaserverfaces.java.net

Re: JAVASERVERFACES-3939

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Mon, 18 Jan 2016 09:04:04 +0100

On Mon, Jan 18, 2016 at 8:44 AM, Xavier Dury <kalgon_at_hotmail.com> wrote:

> Incoming requests are handled fine (and without the warning) but rewriting
> links is messed up.
>

Thanks for the followup. This could potentially be a PrettyFaces issue.
What does "messed up" means?

1. Link does not render at all
2. Crash / exception when link is rendered
3. Wrong parameter names and/or wrong parameter values in link
4. Something else?

What happens when you use "/foo/#{someBean.param}", which was said to be
specifically supported?



>
> Xavier
> ________________________________
> > Date: Fri, 15 Jan 2016 20:21:26 +0100
> > Subject: Re: JAVASERVERFACES-3939
> > From: arjan.tijms_at_gmail.com
> > To: dev_at_javaserverfaces.java.net
> >
> > It's not a PrettyFaces bug for sure. I glanced over the code, and I'm
> > fairly sure they just write to whatever value expression you supply. As
> > per Christian's reply, "/foo/#{someBean.param}" works as well,
> > so "/foo/#{requestScope.id}" should work too.
> >
> > The only question is whether "/foo/#{id}" doesn't trigger some special
> > behaviour where the value after /foo/ is not just written to the value
> > expression, but also transformed into a query parameter.
> >
> > At any length, just using #{name} is what triggers the scope searching,
> > which on its turn triggers the problematic behaviour.
> >
> > I've to double check what the spec says about this though.
> >
> >
> >
> >
> >
> > On Fri, Jan 15, 2016 at 7:58 PM, Xavier Dury
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com>> wrote:
> > Ok, I will try with #{requestScope.id} instead of #{id}.
> >
> > I originally thought it was a prettyfaces bug. If you have better
> > arguments than me, you could still leave a comment
> > at https://github.com/ocpsoft/rewrite/issues/208.
> >
> > ________________________________
> > Date: Fri, 15 Jan 2016 19:27:13 +0100
> >
> > Subject: Re: JAVASERVERFACES-3939
> > From: arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>
> > To: dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net>
> >
> > Hi,
> >
> > On Fri, Jan 15, 2016 at 7:15 PM, Xavier Dury
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com>> wrote:
> > <url-mapping id="document">
> > <pattern value="/document/#{id}" />
> > <view-id value="/document.xhtml" />
> > </url-mapping>
> >
> > I don't think replacing #{id} with #{requestScope.id} in the
> > prettyfaces configuration will work.
> >
> > Okay, so it's PrettyFaces that essentially does the write to #{id}
> > which will end up in request scope? (I don't know PrettyFaces that
> > well).
> >
> > Depending on what PrettyFaces exactly does you could try it though. If
> > it's a general value expression where whatever comes after /document/
> > is written to it may actually have a chance of working.
> >
> > I don't know if there are other places in the code where
> > UIViewRoot.getViewMap() is being called without considering that the
> > current view may be transient.
> >
> > I think the view being transient or not does not even matter that much.
> > After all, you can also have a view that simply doesn't use a form (so
> > no state) or have state written to the client.
> >
> > What (IMHO) matters most is that code, and specifically frameworks,
> > should always be wary of accidentally creating sessions when not
> > strictly necessary.
> >
> >
> >
> >
> >
> >
> > ________________________________
> > Date: Fri, 15 Jan 2016 17:18:57 +0100
> > Subject: Re: JAVASERVERFACES-3939
> > From: arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>
> > To: dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net>
> >
> > Hi,
> >
> > On Fri, Jan 15, 2016 at 4:31 PM, Xavier Dury
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com>> wrote:
> >
> > 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 code seems indeed problematic. The view map is created only to
> > check it, which not only causes an annoying warning, it also causes the
> > creation of a session.
> >
> > The same thing holds for the session map check.
> > ec.getSessionMap().get(attribute) will create a session, even when this
> > would not be needed.
> >
> > For some types of applications, the needless creation of sessions is a
> > serious problem. So regardless of the message being annoying or not, or
> > clear or not, this session creation seems problematic to me.
> >
> > The question is; how strict is the spec about mandating this?
> >
> > Regardless, wouldn't changing the value expression mentioned in the
> > issue to one that explicitly contains the scope work around a
> > particular instance of this problem?
> >
> > E.g.
> >
> > ValueExpression ve = ef.createValueExpression(context.getELContext(),
> > "#{requestScope.id}", Object.class);
> >
> > instead of
> >
> > ValueExpression ve = ef.createValueExpression(context.getELContext(),
> > "#{id}", Object.class);
> >
> > ?
> >
> >
> >
> >
> >
> >
> >
> >
>
>