JSF lifecycle query

Hi
My JSF application contains about 6 different jsp pages. Each of these jsp pages contains several richfaces components. Hence for example, in my home.jsp page, clicking on the LHS menu(commandButtons etc) will result in different content appearing in an <a4j:outputPanel> component in the center of the page(home.jsp), i.e. I have the ajaxRendered property set to true for the <a4j:outputPanel> and the commandButtons have their reRender property set to the <a4j:outputPanel>.Hence the user can perform several actions, i.e. loading different content etc (in the a4j:outputPanel) whilst staying on the same view (home.jsp Page) -
I have a requirement to implement a back link(in all my JSP pages). Assume the user navigates to the home.jsp page from the contactus.jsp page and clicks on different menu items within home.jsp which results in different content been loaded in to the <a4j:outputPanel> component in the center of the page. Now, if the user clicks on this back link, I want the back link to return to the previous state of the home.jsp(view) and not the contactus.jsp page.
Is this supported within JSF. Otherwise, if the user clicks on the back link I am going to have the call the various backend methods again to retrieve the data to rebuild the previous state of the current view
Thanks

Maybe you can use a collection into the session to store the history of navigation.
You can construct it with a filter that intercept the request and add a new "navigation" to this collection. (Maybe a list).
and you put a CommnadLink attached with an action that read the previus request and redirect the flow to this page.
The problem is to mange all the logic in you application. One thing is return to the page and other very different return to the last state of the previus page.

Similar Messages

  • High cpu usage during JSF lifecycle phase execution

    In our performance test we encountered a high cpu usage (100%) and the thread dumps indicated that most of the times the threads are either executing restore view or render response phase of the JSF lifecycle or they are blocked while accessing the jar files which containing the xhtml pages.
    One of the thread dump of a runnable thread is
    java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.get(HashMap.java:317)
    at javax.faces.component.ComponentStateHelper.get(ComponentStateHelper.java:174)
    at javax.faces.component.ComponentStateHelper.add(ComponentStateHelper.java:216)
    at javax.faces.component.UIComponent.setValueExpression(UIComponent.java:436)
    at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler$CompositeComponentRule$CompositeExpressionMetadata.applyMetadata(CompositeComponentTagHandler.java:631)
    at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
    at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
    at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.setAttributes(CompositeComponentTagHandler.java:246)
    at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyNextHandler(CompositeComponentTagHandler.java:184)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
    at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:107)
    at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
    at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
    at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:112)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
    at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
    at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:774)
    at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)while a thread trace for a blocked thread is
    java.lang.Thread.State: BLOCKED (on object monitor)
    at java.util.zip.ZipFile.getEntry(ZipFile.java:302)
    - waiting to lock <0x00000000c0f678f8> (a java.util.jar.JarFile)
    at java.util.jar.JarFile.getEntry(JarFile.java:225)
    at java.util.jar.JarFile.getJarEntry(JarFile.java:208)
    at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:817)
    at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:795)
    at sun.misc.URLClassPath.findResource(URLClassPath.java:172)
    at java.net.URLClassLoader$2.run(URLClassLoader.java:551)
    at java.net.URLClassLoader$2.run(URLClassLoader.java:549)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findResource(URLClassLoader.java:548)
    at java.lang.ClassLoader.getResource(ClassLoader.java:1138)
    at java.lang.ClassLoader.getResource(ClassLoader.java:1133)
    at org.glassfish.web.loader.WebappClassLoader.getResource(WebappClassLoader.java:1156)
    at org.glassfish.web.loader.WebappClassLoader.getResourceFromJars(WebappClassLoader.java:1111)
    at org.apache.catalina.core.StandardContext.getMetaInfResource(StandardContext.java:7586)
    at org.apache.catalina.core.StandardContext.getResource(StandardContext.java:6979)
    at org.apache.catalina.core.ApplicationContext.getResource(ApplicationContext.java:382)
    at org.apache.catalina.core.ApplicationContextFacade.getResource(ApplicationContextFacade.java:260)
    at com.sun.faces.context.ExternalContextImpl.getResource(ExternalContextImpl.java:502)
    at com.sun.faces.application.resource.WebappResourceHelper.getURL(WebappResourceHelper.java:119)
    at com.sun.faces.application.resource.ResourceImpl.getURL(ResourceImpl.java:190)
    at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyCompositeComponent(CompositeComponentTagHandler.java:366)
    at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyNextHandler(CompositeComponentTagHandler.java:191)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
    at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:107)
    at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
    at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
    at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:112)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
    at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
    at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
    at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
    at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
    at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
    at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:774)
    at com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:223)
    at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:188)
    at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:453)
    at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
    at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)We use glassfish 3.1.1 as our application and the project_stage property is set to System_test. I would like to get suggestions on how should I investigate this further. Is this a normal behavior? Does glassfish provide an alternative for resolving blocked threads like some caching mechanism for resources etc?
    Thanks in advance

    Nik wrote:
    Even if it is legal, have you tried moving them out of there (just to pinpoint a possible bug since the stacktrace indicates a wait on a jar file)?Indeed. If that clears up the issue it is good information to put in a JSF bug report (which may even cascade to the Glassfish level).
    Putting resources in a jar file is only really useful when you want to share those resources among different web applications, which should be a rare case. Even when it happens I would probably still choose to simply copy the resources so they are individually managed and you don't get unnecessary dependencies between applications. Just because something is technically possible doesn't make it a good idea.

  • What does the scriptcollector do and how does it related to jsf lifecycle?

    hi,
    i want to know what does the scriptcollector do and how does it related to jsf lifecycle? and also in the scriptcollector if i call this,
    preRender=#{myBean.onPageLoadBegin}
    postRender=#{myBean.onPageLoadEnd}
    how my page will react?

    The hx:scriptCollector is part of the IBM Faces Client Framework and has nothing to do with Sun JSF RI.
    Lot of the hx components require specific Javascript and those hx components should be placed inside a single hx:scriptCollector which on its turn checks the nested hx components and renders the desired Javascript for it at the end of the tag. Check the HTML source for that Javascript.

  • Problem with JSF lifecycle

    1> Create a index.html page which loads menu.jsp in frame 1 and search.jsp in frame 2
    2> menu.jsp --- define target as frame 2. Insert a command button, the action event of which re-loads search.jsp in frame 2
    3> search.jsp ---- insert one input text box.
    4> Start server and execute index.html on the server
    5> Click on command button in menu.jsp, it loads search.jsp in frame 2...ok...no problem....
    6> Keep on clicking the command link....after X number of clicks the menu.jsp gets loaded into frame 2.
    7> Click again and the cycle starts again...again after X number of clicks the menu.jsp gets loaded into frame 2.
    I have found that whenever the menu.jsp gets loaded in frame 2, the "Apply Request Values" phase and subsequent phases till the "Invoke Application" phase is not called.....Basically the menu.jsp page is not posted. In my case the X always turned out to be 18. I am testing on Websphere 5.1.2.
    Is this is bug in JSF lifecycle implementation OR a Webshere issue ?
    Appreciate any help in this regard.

    Thanks.
    Does anyone know if there is a patch available for WAS 5.1.2 to fix this problem ? OR is there any other solution because our company will not move to RAD 6 in the near future...Thks

  • Slow performance during Apply Request Values Phase of JSF lifecycle

    Dear all,
    I found that my application is sucked at the Apply Request Values Phase of JSF lifecycle when I submit the page. (Totally spend 1 min to pass this phase)
    In the application, there is around 300 input fields in the page. Who know how can I ehance the performace?
    Thanks.

    Thanks a lot for your help. Maybe I explain more about my current structure
    I need to develop a input form for course instructor to input students' assignment / examination result (max 9 assignments and 1 examination).
    so that I have below coding:
    *1. bean to store marks of a student*
    public class Mark {
    private String studentID = "";
    private String mark1 = "";
    private String mark9 = "";
    private String markExam = "";
    //getter & setter of above properties
    public void setMark1(String mark1) {
    this.mark1 = mark1;
    public String getMark1() {
    return this.mark1;
    *2. backing bean*
    public class markHandler {
    ArrayList<Mark> marks = new ArrayList<Mark>();
    //getter & setter of above property
    //method to retrieve list of student (this will be the action before go in mark input page)
    public void getStudentList() {
    //get student list from database
    for(int i = 0 ; i < studentCount; i++){
    //initial mark of student
    Mark mark = new Mark();
    mark.setStudentID(studentID);
    mark.setMark1("");
    mark.setMarkExam("");
    //put into arraylist
    marks.add(mark);
    *3. mark input page*
    <html>
    <h:dataTable value="#{markHandler.marks}" var="e">
    <column>
    <h:output value="#{e.studentID}" />
    </column>
    <column>
    <h:input id="mark1" value="#{e.mark1}" />
    </column>
    <column>
    <h:input id="mark1" value="#{e.markExam}" />
    </column>
    </h:dataTable>
    <h:commandButton action="#{markHandler.save} />
    </html>
    When I submit the page, It seems that there is a long time spent at the input field of datatable at Apply Request Values Phase. (I use Phase Listeners to test the time difference before & after phase)
    Pls help. Thanks.
    Edited by: Daniel_problem on Aug 15, 2008 10:34 AM
    Edited by: Daniel_problem on Aug 15, 2008 10:36 AM

  • Has anyone really understood the JSF LifeCycle

    I have created my own phase listener :
    public class MyPhaseListner implements PhaseListener {
    public void afterPhase(PhaseEvent evt) {
    System.out.println("EXITING : " + evt.getPhaseId());
    public void beforePhase(PhaseEvent evt) {      
    System.out.println("ENTERING : " + evt.getPhaseId());
    public PhaseId getPhaseId() {
    return PhaseId.ANY_PHASE;
    When i display my page first time I am getting the following output :
    ENTERING : RESTORE_VIEW 1
    EXITING : RESTORE_VIEW 1
    ENTERING : RENDER_RESPONSE 6
    Inside Constructor
    Managed Bean Created.......
    Thank you !!!!
    EXITING : RENDER_RESPONSE 6
    ENTERING : RESTORE_VIEW 1
    EXITING : RESTORE_VIEW 1
    ENTERING : RENDER_RESPONSE 6
    EXITING : RENDER_RESPONSE 6
    ENTERING : RESTORE_VIEW 1
    EXITING : RESTORE_VIEW 1
    ENTERING : RENDER_RESPONSE 6
    ENTERING : RESTORE_VIEW 1
    EXITING : RESTORE_VIEW 1
    ENTERING : RENDER_RESPONSE 6
    EXITING : RENDER_RESPONSE 6
    EXITING : RENDER_RESPONSE 6
    As per my knowledge I can understand first 4 statements(before "*****") outputted.
    An empty view is created and then render response phase is reached skipping all intermediate steps being the first request to JSF page.
    However I can not understand further calls made by JSF lifecycle.
    Can anyone elaborate me more on this?
    Also I am very much interested in some strange number displayed after every phaseId !!!!!

    Hi Sergy !
    Thanks for your reply.!!!!
    Well actually I have some style-sheets and images on my page.
    I think JSF even treats these elements to be a seapare entity.
    So all other statements were for these elements.
    Well I have modified my phase Listener to reflect the view Id as well.
    Below is the class...if anyone is interested !!!
    package util;
    import javax.faces.component.UIViewRoot;
    import javax.faces.event.PhaseEvent;
    import javax.faces.event.PhaseId;
    import javax.faces.event.PhaseListener;
    public class MyPhaseListner implements PhaseListener {
         public void afterPhase(PhaseEvent evt) {
         UIViewRoot root = evt.getFacesContext().getViewRoot();
         if(root == null){
              System.out.println("EXITING : " + evt.getPhaseId());
         }else{
              System.out.println("EXITING : " + evt.getPhaseId() + root.getViewId());
         public void beforePhase(PhaseEvent evt) {
              UIViewRoot root = evt.getFacesContext().getViewRoot();
              if(root != null){
                   System.out.println("ENTERING : " + evt.getPhaseId() + root.getViewId());
              }else{
                   System.out.println("ENTERING : " + evt.getPhaseId());
         public PhaseId getPhaseId() {
              return PhaseId.ANY_PHASE;
    }

  • Making the most of the JSF lifecycle

    I have read through some documenation for the JSF lifecycle, I am wondering though how you would really take advantage of it?
    One of the purposes of JSF was to insulate the developer from having too know much about HTTP. However, how much do they really need to know about JSF lifecycle and what cool things are there that really show the usefullness of this lifecycle being exposed?
    Thanks.

    beginner2 wrote:
    I have read through some documenation for the JSF lifecycle, I am wondering though how you would really take advantage of it?You don't. The phases of the lifecycle are just how JSF ticks; they are not there to make your life easier, they are a design choice you have to know about and have to know how to design around. Not knowing about them is eventually going to lead to unexpected behavior caused by wrong assumptions.
    One of the purposes of JSF was to insulate the developer from having too know much about HTTP. Utter nonsense, IMO. To use JSF, you should be incredibly familiar with HTTP, HTML and Javascript. Sticking your head in the sand and not taking the time to know the very foundation you are working on is going to make you step in a pothole and hurt yourself badly sooner rather than later.
    Of course, that does not stop people from trying. If you want to meet them, they regularly post "how do I do this", "why does this happen" and "bug in JSF?" questions right here in this forum.
    However, how much do they really need to know about JSF lifecycleKnow what each phase of the lifecycle does and in which order they are executed. Know when a phase will be skipped. That is in my opinion what you should know to avoid the gotchas.
    and what cool things are there that really show the usefullness of this lifecycle being exposed?See previous statements.

  • Where in the JSF lifecycle does submittedValue, localVaue, value get set?

    Where in the JSF lifecycle does submittedValue, localVaue and value get set? I was looking at those values on a hidden input field and it was not clear to me in what phases the various values get set. It seemed like sometimes one was set, sometimes the other was set. It was not clear to me how to know where to look for the value (other than try one if that was null try another).
    Brian

    BHiltbrunner wrote:
    Where in the JSF lifecycle does submittedValueIt will be set during the apply request values phase, in the decode() method of the HtmlBasicRenderer.
    It will be reset to null during the process validations phase, in the validate() method of the UIInput.
    localValue and value get set? Those will be set during the process validations phase, in the validate() method of the UIInput.
    The difference is that 'localValue' represents the actual and unevaluated value, and 'value' represents the outcome of the evaluated ValueExpression value.
    I was looking at those values on a hidden input field and it was not clear to me in what phases the various values get set. It seemed like sometimes one was set, sometimes the other was set. It was not clear to me how to know where to look for the value (other than try one if that was null try another).Depends on the where and when you're going to check them.

  • ValueChangeListener fires in JSF lifecycle on a typical actionListener?

    Why does a valueChangeListener on a selectOneChoice fire in the JSF Lifecycle when I click on a separate non-related commandButton that runs an actionListener?
    How do I prevent a valueChangeListener to not fire when I click on a commandButton that runs an actionListener?
    <af:selectOneChoice id="overrideDevice"
    label="#{common.labelOverrideDevice}"
    required="true"
    unselectedLabel="#{common.selectionRequired}"
    value="#{resend.overrideDevice}"
    autoSubmit="true"
    immediate="true"
    valueChangeListener="#{resend.valueChanged}"
    binding="#{resend.overrideDeviceSelect}">
    <f:selectItems value="#{resend.overrideDeviceList}" />
    </af:selectOneChoice>
    and
    <af:commandButton id="bSearch"
    text="#{common.tbFind}"
    actionListener="#{resend.doSearch}"/>
    Thanks,
    --Todd                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    That caused a blank page to be rendered. After the user clicked on the commandButton and fired the actionListener, the valueChangeListener fired; the JSF Lifecycle jumped from APPLY_REQUEST to termination as soon as the APPLY_REQUEST phased completed.
    I can see this happening as I debug the application.
    I'm still at a lost of why a valueChangeListener would fire..?
    Thanks,
    --Todd                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Iframe shortcircuits JSF Lifecycle

    I need to find out why using an <iframe> element in my jsp page under JSF (with or without a <verbatim> tag
    SHORT-CIRCUITS THE JSF LIFECYCLE?
    ie: it goes right to after renderresponse completely bypassing validation and data binding!!
    PLEASE HELP!!!

    Hi,
    The following are the steps I followed:
    1. Create a new project
    2. Drag and drop a textField
    3. In the properties sheet check the required property for the textField
    4. Drag and drop a button and an outputText
    5. Right click on the session bean in the Project Navigator and add a property named txtVal
    6. Double click on the button and in the button_action method enter the following lines of code
    getSessionBean1().setTxtVal((String)textField1.getValue());
    outputText1.setValue(getSessionBean1().getTxtVal());
    7. Click on the jsp tab for the page1.jsp and add the following lines of code inside the form tags
    <iframe align="right" height="80" src="http://www.yahoo.com" style="left: 48px; top: 264px; position: absolute" width="40%">
    <p>See our newsflashes.</p>
    </iframe>
    8. Switch to the design view of Page1.jsp
    9. Drag and drop a message list component onto Page1.jsp
    10. Drag and drop a datatable
    11. Drag and drop the PERSON table from the travel database
    12. Save and run the application
    On clicking on the button without entering a value we see that an error message " Validation Error: Value is required." is displayed by the message component. Also the rest of the components like the datatable also display tthe expected values.
    Hope this helps
    Cheers
    Giri :-)

  • JSF lifecycle : render view

    Was just having look at logs of a JSF application, below are the output's from PhaseListener
    RESTORE_VIEW(1)
    APPLY_REQUEST_VALUES(2)
    RESTORE_VIEW(1)
    RENDER_RESPONSE(6)
    How come RESTORE_VIEW is called after APPLY_REQUEST_VALUES, from JSF lifecycle it seems
    that they are executed in certain order(although some can be skipped)
    Regards,
    Joshua

    Multiple requests?
    Without an SSCCE it's only guessing to an answer.

  • Simple component binding/JSF lifecycle question

    As a JSF newbie, I ran into an unexpected component binding state/JSF lifecycle issue. Given this JSP code:
    <h:inputText id="boundinput" binding="#{UserBean.boundInput}">and this Java setter code:
           private UIInput boundInput = new UIInput();
            public void setBoundInput(UIInput aBoundInput) {
                this.boundInput = aBoundInput;
                String value = aBoundInput.getValue();
            }the result of 'value' is the previous value of the input text field when the form is submitted. The component is bound, but why isn't the new value available?
    It seems to get the 'current' value of the bound component, a valueChangeListener has to be implemented? I may be missing something fundamental, so any help is appreciated.

    If you only want to get and set values, use valuebinding instead.
    If you're debugging the setBoundInput after form input, then yes, it is correct that the old value is still in there. This would be updated at a later JSF phase yet.
    Check http://balusc.xs4all.nl/srv/dev-jep-djl.html to get some insights in the JSF lifecycle.

  • Best practice how to retrieve & update data w/o any jsf-lifecycle-overhead

    I have a request scoped jsf managed bean called "ManagedBean". This bean has a method annotated with "@PostConstruct" that retrieves data from a database. The data is shown in a jsp "showAndEditData.jsp" in <h:inputText /> components - so the data is editable.
    The workflow is as follows:
    First, when navigating to "showAndEditData.jsp", the ManagedBean is created, the "@PostConstruct"-method is invoked, and the data retrieved from the database is shown to the user.
    Second, the user changes the data.
    Third, the user presses the submit button, the ManagedBean is created again, the "@PostConstruct"-method is invoked again, and the data is retrieved from the database again. Then the data is overridden by the changes the user made and passed to the business-tier (where it will be saved to the database).
    Every step that i marked with "*again*" is completely unneccessary and a huge overhead.
    Is there a way to prevent these unneccessary steps.
    Or asking in other words: Is there a best practice how to retrieve and update data efficently and without any overhead using JSF?
    I do not want to use session scoped managed beans, because this would be a huge overhead as well.

    The first "again" is neccessary, because after successfull validation, you need new object in request to store the submitted value.
    I agree to the second and third, really unneccessary and does not make sense.
    Additionally I think it�s bad practice putting data in session beansTotal agree, its a disadvantage of JSF that we often must use session.
    Think there is also an bigger problem with this.
    Dont know how your apps are working, my apps start an new database transaction per commit on every new request.
    So in this case, if you do an second query on postback, which uses an different database transaction, it could get different data as for the inital request.
    But user did his changes <b>accordingly</b> to values of the first snapshot during the inital request.
    If these values would be queried again on postback, and they have been changed meanwhile, it becomes inconsistent, because values of snapshot two, do not fit to user input.
    In my opionion zebhed has posted an major mistake in JSF.
    Dont now, where to store the data, perhaps page scope could solve this.
    Not very knowledge of that section, but still ask myself, if this data perhaps could be stored in the components and on an postback the data are rendered from components + submittedvalues instead of model.

  • JSF general query regarding UISelectItem and UISelectItems

    I am seeing a couple of peculiar behavior and i have no explanation for them at the moment . It would be great if someone can explain the apparently different behavior of JSF in general.
    Whenever there is 'n' number of UISelectItem components inside a UISelectOne component , the getter method of the property of the backing bean to which the UISelectOne component's value is bound is getting called "n" number of times when the page is rendered.
    Whenever there is a single UISelectItems component inside a parent UIselectOne component , the getter method of the property(in my case a List of SelectItem components) of the backing bean to which the UISelectItems component's value is bound is getting called "2" times when the page is rendered.
    The pattern is same for the first time when the page is requested and for any subsequent requests for the page.
    What might be the possible reason for the afore mentioned behaviors of JSF?

    Getters and setters will be called different times in different Lifecycle phases.
    This may help... http://www-128.ibm.com/developerworks/java/library/j-jsf2/
    in particular, Select Components have some validation checks that loop over the items in the select component - I believe basically it loops over the selectItems and makes sure the selectItem.value "type" is the same as the selectComponent.value "type"
    Also... I just posted this to another thread....
    I found adding a Phase Listener with debug logging has helped enourmously with seeing when getter and setters were called in which phase.
    public class DebugPhaseListener implements PhaseListener {
        private static final Log LOGGER = LogFactory.getLog(DebugPhaseListener.class);
        public PhaseId getPhaseId() {
            return PhaseId.ANY_PHASE;
        public void beforePhase(PhaseEvent event) {
            LOGGER.debug("beforePhase(" + event.getPhaseId() + ")");
        public void afterPhase(PhaseEvent event) {
            LOGGER.debug("afterPhase(" + event.getPhaseId() + ")");
    in your faces-config.xml... add
    <lifecycle>
    <phase-listener>com.mycompany.DebugPhaseListener</phase-listener>
    </lifecycle>

  • Customize JSF LifeCycle

    Hi all,
    Presently i am working on JDeveloper 11g. I want to customize JSF PageLifecycle in my project for customizing error messages to get proper error messages to the client. Can anybody help me ?

    This question has been ask here before. Have you searched the forum?
    Did you check the docs?
    [26.8 Customizing Error Handling|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/web_adv.htm#CIHHBEEJ] shows how to do this.
    For the life cycle read [19 Understanding the Fusion Page Lifecycle|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/adf_lifecycle.htm]
    Timo

Maybe you are looking for