Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: Solaris
      Platform: Sun

    • Issuezilla Id:
      216

      Description

      I am NOT SURE whether i will get ANSWER to my QUERY so i am quite PESSIMISTIC
      with this Forum as i am yet to get an ANSWER for my early query

      Anyhow here is my posting
      My requirement is
      " Our users are Authenticated by External System . On successful
      authentication the external system returns header variables viz. userId,
      firstName, lastName etc to our System.
      Currently I am able to retrieve these header variables using
      request.getHeader("userId") in my JSP page.
      But this is certainly not the best practice. I am thinking of storing this
      information in Backing Bean via Phase Listener for further use like
      1) retrieving user Roles from the Database based on userId and
      2) displaying JSP page based on user roles

      I am not sure how to tie up PhaseListener with the Backing Bean .
      What are the Best Practices

      Here are my snippets of code

      --------------------
      Faces-config.xml :
      --------------------
      <lifecycle>
      <phase-listener>
      com.mycompany.MyPhaseListener
      </phase-listener>

      <managed-bean>
      <managed-bean-name>greetingForm</managed-bean-name>
      <managed-bean-class>com.mycompany.GreetingForm</managed-bean-class>
      <managed-bean-scope>request</managed-bean-scope>
      <managed-property>
      <property-name>id</property-name>
      <value>#

      {param.id}

      </value>
      </managed-property>
      <managed-property>
      <property-name>testSpringBean</property-name>
      <property-class>
      com.mycompany.TestSpringBean
      </property-class>
      <value>#

      {testSpringBean}

      </value>
      </managed-property>
      </managed-bean>

      --------------------
      MyPhaseListener
      --------------------
      public void afterPhase(PhaseEvent pe)

      { System.out.println("after - " + pe.getPhaseId().toString()); if (pe.getPhaseId() == PhaseId.RENDER_RESPONSE) System.out.println("Done with Request!\n"); Map requestHeaderMap = new HashMap(); requestHeaderMap = pe.getFacesContext().getExternalContext().getRequestHeaderMap(); System.out.println("Hash Map Size:"+requestHeaderMap.size()); String bemsId = (String)requestHeaderMap.get("USERID"); System.out.println("userId="+userId); }

      Any pointers/suggestions with little snippets of code will be highly
      appreciated

      Regards
      Bansi

        Issue Links

          Activity

          Hide
          kito75 added a comment -

          I would think we could close this issue, as this is possible using the
          phaseListener attribute on the <f:view> tag or the <f:phaseListener> tag in JSF 1.2.

          Show
          kito75 added a comment - I would think we could close this issue, as this is possible using the phaseListener attribute on the <f:view> tag or the <f:phaseListener> tag in JSF 1.2.
          Hide
          Ryan Lubke added a comment -

          This is a user, and possibly an implementation issue, but not an issue with the
          spec (agree with Kito that the 1.2 phase listeners on the UIViewRoot can
          associate be associated with a specific bean)

          Show
          Ryan Lubke added a comment - This is a user, and possibly an implementation issue, but not an issue with the spec (agree with Kito that the 1.2 phase listeners on the UIViewRoot can associate be associated with a specific bean)
          Hide
          Ed Burns added a comment -

          Per 20080820 EG meeting, I am taking action on these issues.

          Show
          Ed Burns added a comment - Per 20080820 EG meeting, I am taking action on these issues.
          Hide
          Ed Burns added a comment -

          Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed
          already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases,
          this means the EG deemed that the issue isn't appropriate for fixing.

          If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.

          Show
          Ed Burns added a comment - Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases, this means the EG deemed that the issue isn't appropriate for fixing. If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.
          Hide
          Ed Burns added a comment -

          Prepare to delete "implementation" subcomponent.

          Show
          Ed Burns added a comment - Prepare to delete "implementation" subcomponent.
          Hide
          Ed Burns added a comment -

          Move all to 1.2

          Show
          Ed Burns added a comment - Move all to 1.2
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              mail2bansi
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: