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.

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.

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;
}

JSF 2.0: View Scope Problem

Hey,
I 'm having trouble using the JSF 2.0 view scope. My application is a search page displaying some search parameters and a list of results. The search parameters are backed by a session scope bean, the results a backed by a request scoped bean and there is some kind of controller bean in request scope, too. Searching and displaying the results works fine.
The second step was some kind of details page to display when clicking on one result element. I have another controller bean for this goal, but when pressing the link the requested action is not performed. I remembered similar problems I had in the past where I put the bean containing the result list into view scope.
But after putting the results bean into view scope searching is not working anymore. You click the search button, the search action is performed. But after successfully storing the results a new results bean is instantiated. An empty one of course.
Now I 'm not sure anymore if I understand the view scope: I have a single page, I search something and the results are displayed on the same page. I cannot believe that request scoped results work fine and view scoped results do not.
Can anyone help me?
Thanks,
Stephan

I found the problem and a solution :-) The missing piece of the puzzle was the id attribute for the form tag. After some debugging of the JSF JavaScript I found the solution.
The JavaScript function response(request, context) is invoked to handle the server response. Inside this function the doUpdate(element, context) is invoked.
The doUpdate() function is doing the modification of the DOM. The function doUpdate() is two times invoked for a response. The first time the html elements are updated.
The second time the view state hidden field is updated or created but only under the following condition:
Comment in the JavaScript source code of the jsf.js
//Now set the view state from the server into the DOM
//but only for the form that submitted the request.If the forms of the both side haven't the same id the form can't be found on the second page.
In the following way it is working:
page1.xhtml
<h:form id="myform">
        <h:commandLink value="Go to page 2" action="page2">
            <f:ajax render="@all" execute="@all"/>
        </h:commandLink>
</h:form>
.....page2.xhtml
<h:form id="myform">
            <h:commandLink value="Go to page 1" action="page1">
                <f:ajax render="@all" execute="@all"/>
            </h:commandLink>
</h:form>So always set an explicit id for each JSF tag.

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 2.0 view handler

JDeveloper documentation has an error in configuring the view handler.
http://download.oracle.com/docs/cd/E16162_01/user.1112/e17455/dev_wpt.htm#OJDUG3574
Example 11-4 Facelet Code Added to Your faces-config.xml
<application>
<view-handler>com.sun.Facelets.FaceletViewHandler</view-handler>
</application>
com.sun.Facelets.FaceletViewHandler is the JSF 1.2 view handler. For JSF 2.0 a view handler is not to be configured.
Edited by: dvohra16 on Jul 7, 2012 2:07 PM

Thank-you for pointing out this in our documentation. I have removed this section since the faces-config.xml does not get modified to add the view handler detail in JSF 2.0. when one adds a facelet page.
Edited by: user742463 on Jul 10, 2012 1:30 PM

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

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

Integration of Spring, JSF as a view through portlets...

I am trying to integrate Spring and JSF as a View. Furthermore I am trying to run this combination within a Portlet environment. I have got as far as been able to display the components by the url on the form post is not the portlet action URL as it should be. Can someone look at this thread and perhaps propose a next step.
http://forum.springframework.org/viewtopic.php?t=4950

Hi
If you are new to EBS then read up on EBS. Take a look at:
http://www.packtpub.com/service-oriented-java-business-integration
http://en.wikipedia.org/wiki/Enterprise_service_bus
In Siebel take a look at Bookshelf:
Transports and Interfaces:
Siebel eBusiness Application Integration Volume III
and
Integration Platform Technologies:
Siebel eBusiness Application Integration Volume ll
For Siebel 8.0 you find it here:
http://download.oracle.com/docs/cd/B40099_02/books/EAI3/EAI3TOC.html
Axel

Cisco Prime 2.0 Classic Theme vs Lifecycle Theme view

Is the Livecycle Theme being retired?
This is a 2 part question.
In a course I just finished, it was mentioned that in the next release of CPI, the Lifecycle Theme view was being removed.
Is this correct?
Based on the comments from the course instructure, I did a comparison of the two themes.
What I discovered is that, in the Classic Theme view, I am unable to see any of the routers that I've created via the Lifecycle Theme.
I am, however, able to view the routers in reports that I created in the Classic Theme. The data is there, it's just not being displayed.
Are there plans to correct this, or am I missing something?
Regards,
Doug Moffat
Senior Operations Engineer
Sunlife of Canada

Hi Doug,
From PI 2.2 onwards , Classic theme will be deprecated NOT the LifeCycle theme.
Check the attached screen shot.
Hopefully you will see all the options under LifeCycle theme from 2.2 onwards
Thanks-
Afroz
****Ratings Encourages Contributors ****

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.

JSF lifecycle : render view

Similar Messages

Maybe you are looking for