The suggested fix is not viable in the ICEfaces 1.8 code: initialRequest is a temporary variable only. This avoids requests being referenced outside of their normal lifecycle (such as during push renders).

An alternative suggested fix is to ensure that the Authorization implementation has the request available to it (provided in the following comment).

— src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java (revision 19721)
+++ src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java (working copy)
@@ -58,7 +58,7 @@
try

finally

• private void addRequest(HttpServletRequest request) {
• String key = request.getRequestedSessionId();
  + private void addRequest(HttpSession session, HttpServletRequest request) {
  + String key = session.getId();
  synchronized (activeRequests) {
  if (activeRequests.containsKey(key)) {
  List requests = (List) activeRequests.get(key);

A similar fix is already in place in ICEfaces 1.8.2. Awaiting customer verification of 1.8.2.

If 1.8.2 is shown to still exhibit the bug, the problem may be with the ordering of the checkSession() and addRequest() calls below:

public void service(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpSession session = request.getSession(true);
checkSession(session);

//attach session bound server to the current thread – this is a lock-free strategy
String id = session.getId();
try {
//put the request in the pool of active request in case HttpServletRequest.isUserInRole need to be called
addRequest(id, request);

checkSession() establishes the isUserInRole() callbacks, but the request objects are not populated until the addRequest() call. Hence, it may be possible for another thread to invoke isUserInRole prior to addRequest(), however, this seems unlikely since this bug is only present on the first page view (hence the first request).

Customer confirms 1.8.2 already has the fix included, so this JIRA is redundant.