> What does "messed up" means?
The rewriting rule is not applied at all, giving something like
http://localhost:8080/document.xhtml?id=1 (without context name) instead of
http://localhost:8080/appctx/document/1
> What happens when you use "/foo/#{someBean.param}", which was said to be specifically supported?
Well, I don't like to use that type of parameter.
You're then forced to put your parameter somewhere in a bean (and how would you do it when you have a collection of urls to write, like in a table?).
I rather write my url like this, which gives me the freedom to specify the parameter in the view so it doesn't matter where it comes from.
<h:outputLink value="/document.xhtml">
<h:outputText value="link" />
<f:param name="id" value="#{whatever.you.want}" />
</h:outputLink>
________________________________
> Date: Mon, 18 Jan 2016 09:04:04 +0100
> Subject: Re: JAVASERVERFACES-3939
> From: arjan.tijms_at_gmail.com
> To: dev_at_javaserverfaces.java.net
>
> On Mon, Jan 18, 2016 at 8:44 AM, Xavier Dury
> <kalgon_at_hotmail.com<mailto: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<mailto:arjan.tijms_at_gmail.com>
>> To: dev_at_javaserverfaces.java.net<mailto: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><mailto: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><mailto:arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>>
>> To:
> dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net><mailto: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><mailto: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><mailto:arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>>
>> To:
> dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net><mailto: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><mailto: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);
>>
>> ?
>>
>>
>>
>>
>>
>>
>>
>>
>
>