Using /document/#{someBean.id} works for incoming requests (someBean.id will be populated with the parameter) but not for rewriting urls (someBean.id won't be picked up automatically to be used in the url pattern if I don't use any f:param).
But if I write the pattern like this /document/#{id : requestScope.id}, everything seems to work:
- I can use <f:param name="id" ...> to output links
- requestScope.id will be populated with the incoming parameter
- no warning will be shown
________________________________
> Date: Mon, 18 Jan 2016 10:28:21 +0100
> Subject: Re: JAVASERVERFACES-3939
> From: arjan.tijms_at_gmail.com
> To: dev_at_javaserverfaces.java.net
>
> On Mon, Jan 18, 2016 at 9:36 AM, Xavier Dury
> <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com>> wrote:
>> 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.
>
> Of course, I don't think many would like that.
>
> But technically #{someBean.param} should be indistinguishable from
> #{requestScope.param}. So if the former does work but the second
> doesn't, it may give us an interesting data point. If #{someBean.param}
> also doesn't work, it's very likely to be a PrettyFaces bug, as they
> seem to mention that that would be supported.
>
> So it would be interesting just to try it and see what happens.
>
>
> <h:outputLink value="/document.xhtml">
> <h:outputText value="link" />
> <f:param name="id" value="#{whatever.you.want}" />
> </h:outputLink>
>
> A trick I used in the past was to declare a request scoped Map (using
> faces-config.xml, but may use a named CDI producer as well I guess) and
> then use that map. E.g.
>
> <f:param name="id" value="#{myMap.whatever}" /> or if you prefer
> <f:param name="id" value="#{myMap['whatever']}" />
>
> Still, that *should* be the same as requestScope.whatever, but to be
> sure it's one extra thing to try.
>
>
>
>
>
>
> ________________________________
>> Date: Mon, 18 Jan 2016 09:04:04 +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>
>>
>> On Mon, Jan 18, 2016 at 8:44 AM, Xavier Dury
>>
> <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com><mailto: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><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>>
>>>
>>> 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>><mailto: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>><mailto: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>><mailto: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>><mailto: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>><mailto: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>><mailto: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>><mailto: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);
>>>
>>> ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>