I moved this discussion to the JSFTemplating email alias... see comments
below.
Anissa Lam wrote:
> Hi,
> I just saw a bug in EE such that listing HttpListeners, AuditModules,
> JaccProviders etc all list those from server-config regardless which
> config you want. Then i look at the code and see that it didn't hard
> coded server-config and seems to be doing the right thing.
>
> getRequestValue(key="configName" value=>$page{configName});
> getListenersList(ConfigName="#{configName}", Type="httpListener"
> Result=>$attribute{listOfRows} );
>
> Some debugging shows that getRequestValue() did return the correct
> configName, not server-config. I realized that
> ConfigName="#{configName} must be picking the configName from session
> scope instead of Page. And in fact, thats the reason. There is a
> configName in the session scope which is used.
>
> That raise a question to Ken regarding the scope of resolving variable.
JSF's pre-set scopes do have a well defined order in which they are
resolved. Relying on this can be a feature... or a source of bugs (as
you've found). Even without pageSession, you can run into this problem
w/ request, session, and application scope. In cases designed to allow
overriding (i.e. request overriding session), this is good... in places
where you expect a specific scope, but use #{variable} syntax, you're
risking a bug b/c it may find it in a different scope.
Solution: Specify the scope you expect.
Here are some ways to define EL expressions to avoid this masking effect:
#{requestScope.foo}
#{sessionScope.foo}
#{applicationScope.foo}
#{pageSession.foo}
$attribute{foo}
$session{foo}
$pageSession{foo}
The #{} should be used in cases where you need a ValueBinding. Using
the #{} syntax, you can also use []'s instead of a '.', for example:
#{requestScope['foo']}.
> Currently, it looks at applications, then session, then page.
Actually I think it's: request scope, session scope, application scope,
then pageSession.
Here's why... The first 3 are JSF standard scopes and behave the way JSF
specifies. I extended the EL to add pageSession, but I didn't want it
to override the other scopes -- I could have tried to search for it
first or last, I chose last. The reason I wanted to do this was b/c I
wanted to give JSF and other custom VariableResolvers the opportunity to
resolve the value before the PageSessionResolver attempted to do this.
This is more likely to be compatible with any other #{} expressions.
So you are correct, pageSession gets a low precedence. HOWEVER, if you
write: #{pageSession.foo} it will resolve more quickly and will not be
overriden.
> Whats the reason for this ordering, seems that there is no way to
> change that variable except to end the session, or even restart the app.
See above.
> Besides the above question, i also want to remind you that unless
> there is a reason, DO NOT set the attribute in the session.
> Also, as Ken has mentioned, since we know the scope of the
> attribute, it gives better performance if we specify it, so, in the
> above case, using $pageSession{configName} will work.
Yep, that's right. Or #{pageSession.configName}
Thanks!
Ken Paulsen
ken.paulsen_at_sun.com
https://jsftemplating.dev.java.net