Friday, January 27, 2012

Free Application to be an Astronaut - Ends today

NASA NEWS:

Joshua Buck
Headquarters, Washington
202-358-1100
jbuck@nasa.gov

Nicole Cloutier-Lemasters
Johnson Space Center, Houston
281-483-5111
nicole.cloutier-1@nasa.gov

Jan. 23, 2012
RELEASE : 12-024
Astronaut Application Deadline Approaching
HOUSTON -- Individuals interested in becoming America's future space explorers have until Friday to submit their applications. The deadline to apply for NASA's next astronaut class is Jan. 27.

The agency typically receives as many as 3,500 applicants for each astronaut class. Thus far, NASA has received more than 3,000 applications since November for this class.

"We are excited about the response we have received, and we want to encourage anyone contemplating this dynamic and exciting career to apply," said Peggy Whitson, chief of the Astronaut Office. "We are entering a new phase in human spaceflight with amazing opportunities to live and work in space. We want the best, the brightest and the most talented mix of professionals to join our team."

Those interested in applying for the astronaut corps can submit their applications through the federal government's USAJobs.gov website. Qualifications include a bachelor's degree in engineering, science or math and three years of relevant professional experience. Educators teaching kindergarten through 12th grade also are encouraged to apply.

NASA expects to announce the final selections in 2013 with initial training to begin that summer.

For more information about the astronaut application and selection process and to follow the latest news via NASA accounts on Twitter, Facebook and YouTube, visit:

http://www.nasa.gov/flynasa

- end -


text-only version of this release

Thursday, January 26, 2012

A description of the differences between 32-bit versions of Windows Vista and 64-bit versions of Windows Vista

System TipThis article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you. Visit the Windows XP Solution Center

On This Page

SUMMARY

This article describes the differences between the 32-bit versions of Windows Vista and the 64-bit versions of Windows Vista.

Note To use a 64-bit version of Windows Vista, you must have a computer that has a 64-bit processor. Also, you must have 64-bit device drivers for the devices that are in the computer.

INTRODUCTION

You may want to determine whether the platform of Windows Vista is installed.

To have us help you determine which platform is installed, go to the "Fix it for me" section. If you would rather fix this problem yourself, go to the "Let me fix it myself" section.

Fix it for me

To determine which platform is installed automatically, click the Fix this problem link. Then click Run in theFile Download dialog box, and follow the steps in this wizard.

Fix this problem
Microsoft Fix it 50525


Note This wizard may be in English only; however, the automatic fix also works for other language versions of Windows.

Note If you are not on the computer that has the problem, you can save the automatic fix to a flash drive or to a CD, and then you can run it on the computer that has the problem.

Let me fix it myself

To determine which Windows Vista platform is installed yourself, follow these steps:
  1. Click Start, right-click Computer, and then click Properties.
  2. The operating system appears as follows:
    • For a 64-bit version operating system, "64-bit Operating System" appears for the system type under System.
    • For a 32-bit version operating system, "32-bit Operating System" appears for the system type under System.
Note Microsoft Win32 uses the x86 processor in 32-bit flat mode. Therefore, a x86-based version means a 32-bit version operating system.

MORE INFORMATION

The main differences between the 32-bit versions of Windows Vista and the 64-bit versions of Windows Vista relate to memory accessibility, memory management, and enhanced security features. The security features that are available in the 64-bit versions of Windows Vista include the following:
  • Kernel Patch Protection
  • Support for hardware-backed Data Execution Protection (DEP)
  • Mandatory driver signing
  • Removal of support for 32-bit drivers
  • Removal of the 16-bit subsystem
One of the greatest advantages of using a 64-bit version of Windows Vista is the ability to access physical memory (RAM) that is above the 4-gigabyte (GB) range. This physical memory is not addressable by 32-bit versions of Windows Vista.

Depending on the version of Windows Vista that is installed, a 64-bit version of Windows Vista supports from 1 GB of RAM to more than 128 GB of RAM. The ability to address more physical memory lets Windows Vista minimize the time that is required to swap processes in and out of physical memory. Therefore, Windows Vista can manage processes more efficiently. This memory management feature helps improve the overall performance of Windows Vista.

Advantages when you install a 64-bit version of Windows Vista

  • Increased memory support beyond that of the 4-GB addressable memory space that is available in a 32-bit operating system
  • Increased program performance for programs that are written to take advantage of a 64-bit operating system
  • Enhanced security features

What to consider when you install a 64-bit version of Windows Vista

  • 64-bit device drivers may not be available for one or more devices in the computer.
  • Device drivers must be digitally signed.
  • 32-bit device drivers are not supported.
  • 32-bit programs may not be fully compatible with a 64-bit operating system.
  • It may be difficult to locate programs that are written specifically for a 64-bit operating system.
  • Not all hardware devices may be compatible with a 64-bit version of Windows Vista.

The main differences between the 32-bit versions of Windows Vista and the 64-bit versions of Windows Vista

ArchitectureWindows Vista, 32-bit versionsWindows Vista, 64-bit versions
System requirements1-gigahertz (GHz) 32-bit (x86) processor or 64-bit (x64) processor, 512 MB of RAM1-GHz 64-bit (x64) processor, 1 GB of RAM (4 GB recommended)
Memory accessA 32-bit version of Windows Vista can access up to 4 GB of RAM.A 64-bit version of Windows Vista can access from 1 GB of RAM to more than 128 GB of RAM.
Memory access per editionAll 32-bit versions of Windows Vista can access up to 4 GB of RAM.Windows Vista Home Basic - 8 GB of RAM
Windows Vista Home Premium - 16 GB of RAM
Windows Vista Business - 128 GB of RAM or more
Windows Vista Enterprise - 128 GB of RAM or more
Windows Vista Ultimate - 128 GB of RAM or more
DEP32-bit versions of Windows Vista use a software-based version of DEP.64-bit versions of Windows Vista support hardware-backed DEP.
Kernel Patch Protection (PatchGuard)This feature is not available in 32-bit versions of Windows Vista.This feature is available in 64-bit versions of Windows Vista. Kernel Patch Protection helps prevent a malicious program from updating the Windows Vista kernel. This feature works by helping to prevent a kernel-mode driver from extending or replacing other kernel services. Also, this feature helps prevent third-party programs from updating (patching) any part of the kernel.
Driver signingUnsigned drivers may be used with 32-bit versions of Windows Vista.64-bit versions of Windows Vista require that all device drivers be digitally signed by the developer.
32-bit driver support32-bit versions of Windows Vista support 32-bit drivers that are designed for Windows Vista.64-bit versions of Windows Vista do not support 32-bit device drivers.
16-bit program support32-bit versions of Windows Vista support 16-bit programs, in part.64-bit versions of Windows Vista do not support 16-bit programs.

Applies to all editions of Windows Vista.

Compare editions

32-bit and 64-bit Windows: frequently asked questions

Here are answers to some common questions about the 32-bit and 64-bit versions ofWindows.

Show all

What is the difference between 32-bit and 64-bit versions of Windows?

The terms 32-bit and 64-bit refer to the way a computer's processor (also called aCPU), handles information. The 64-bit version of Windows handles large amounts of random access memory (RAM) more effectively than a 32-bit system. For more details, go to A description of the differences between 32-bit versions of Windows Vista and 64-bit versions of Windows Vista online.

How can I tell if my computer is running a 32-bit or a 64-bit version of Windows?

To find out if your computer is running 32-bit or 64-bit Windows, do the following:

  1. Open System by clicking the Start button Picture of the Start button, clicking Control Panel, clickingSystem and Maintenance, and then clicking System.

  2. Under System, you can view the system type.

Which version of Windows Vista should I install: the 32-bit version or the 64-bit version?

To install a 64-bit version of Windows Vista, you need a processor that's capable of running a 64-bit version of Windows. The benefits of using a 64-bit operating system are most apparent when you have a large amount of random access memory (RAM) installed on your computer (typically 4 GB of RAM or more). In such cases, because a 64-bit operating system can handle large amounts of memory more efficiently than a 32-bit operating system, a 64-bit operating system can be more responsive when running several programs at the same time and switching between them frequently.

For more information about the benefits of running 64-bit computers, go toUnderstanding 64-bit PCs online.

How do I tell if my computer can run a 64-bit version of Windows?

To run a 64-bit version of Windows, your computer must have a 64-bit-capable processor. To find out if your processor is 64-bit-capable, do the following:

  1. Open Performance Information and Tools by clicking the Start button Picture of the Start button, clickingControl Panel, clicking System and Maintenance, and then clickingPerformance Information and Tools.

  2. Click View and print details.

  3. In the System section, you can see what type of operating system you're currently running under System type. Under 64-bit capable, you can see whether you can run a 64-bit version of Windows. (If your computer is already running a 64-bit version of Windows, you won't see the 64-bit capable listing.)

Can I upgrade from a 32-bit version of Windows to a 64-bit version of Windows?

No. If you are currently running a 32-bit version of Windows, you can only perform an upgrade to another 32-bit version of Windows. Similarly, if you are running a 64-bit version of Windows, you can only perform an upgrade to another 64-bit version ofWindows.

If you want to move from a 32-bit version of Windows to a 64-bit version ofWindows Vista or vice versa, you'll need to back up your files and then choose the Custom option during Windows Vista installation. Then, you'll need to restore your files and reinstall your programs. For more information, see Installing and reinstallingWindows Vista.

For detailed information about installing and upgrading 32-bit and 64-bit versions ofWindows, go to Installation choices for Windows Vista (32-bit) or Installation choices for Windows Vista (64-bit) online.

Notes

Notes

  • To install a 64-bit version of Windows on a computer running a 32-bit version of Windows, you'll need to start, or boot, your computer using a 64-bit Windows installation disc.

  • If you start your computer using a 64-bit Windows installation disc, but your computer isn't capable of running a 64-bit version ofWindows, you'll see a Windows Boot Manager error. You'll need to use a 32-bit Windows installation disc instead.

Can I run 32-bit programs on a 64-bit computer?

Most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows. Notable exceptions are many antivirus programs.

Device drivers designed for 32-bit versions of Windows won't work on computers running a 64-bit version of Windows. If you're trying to install a printer or other device that only has 32-bit drivers available, it won't work correctly on a 64-bit version ofWindows. If you are unsure whether there is a 64-bit driver available for your device, go online to the Windows Vista Compatibility Center.

Can I run 64-bit programs on a 32-bit computer?

If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)

Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.

If I'm running a 64-bit version of Windows, do I need 64-bit drivers for my devices?

Yes, all hardware devices need 64-bit drivers to work on a 64-bit version of Windows. Drivers designed for 32-bit versions of Windows won't work on computers running 64-bit versions of Windows.

If you are unsure whether there is a 64-bit driver available for your device, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.

You can also go online to the Windows Vista Compatibility Center, or get information about drivers by going to the Windows Vista Upgrade Advisor website.

Was this helpful?

Wednesday, January 18, 2012

Debug JSF lifecycle

http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html

Listen and debug JSF lifecycle phases

The JSF lifecycle will be explained and debugged here using the "poor man's debugging" approach with sysout's. We'll also check what happens if you add immediate="true" to the UIInput and UICommand and what happens when aConverterException and ValidatorException will be thrown.

Well, you probably already know that the JSF lifecycle contains 6 phases:

  1. Restore view
  2. Apply request values
  3. Process validations
  4. Update model values
  5. Invoke application
  6. Render response

You can use a PhaseListener to trace the phases of the JSF lifecycle and execute some processes where required. But you can also use a "dummy" PhaseListener to debug the phases to see what is happening in which phase. Here is a basic example of such a LifeCycleListener:

Note: if you don't have a JSF playground environment setup yet, then you may find this tutorial useful as well: JSF tutorial with Eclipse and Tomcat.

package mypackage;  import javax.faces.event.PhaseEvent; import javax.faces.event.PhaseId; import javax.faces.event.PhaseListener;  public class LifeCycleListener implements PhaseListener {      public PhaseId getPhaseId() {         return PhaseId.ANY_PHASE;     }      public void beforePhase(PhaseEvent event) {         System.out.println("START PHASE " + event.getPhaseId());     }      public void afterPhase(PhaseEvent event) {         System.out.println("END PHASE " + event.getPhaseId());     }  }

Add the following lines to the faces-config.xml to activate the LifeCycleListener.

     mypackage.LifeCycleListener 

This produces like the following in the system output:

START PHASE RESTORE_VIEW 1
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
END PHASE APPLY_REQUEST_VALUES 2
START PHASE PROCESS_VALIDATIONS 3
END PHASE PROCESS_VALIDATIONS 3
START PHASE UPDATE_MODEL_VALUES 4
END PHASE UPDATE_MODEL_VALUES 4
START PHASE INVOKE_APPLICATION 5
END PHASE INVOKE_APPLICATION 5
START PHASE RENDER_RESPONSE 6
END PHASE RENDER_RESPONSE 6


Basic debug example

To trace all phases of the JSF lifecycle, here is some sample code which represents simple JSF form with a "dummy" converter and validator and the appropriate backing bean. The code sample can be used to give us more insights into the phases of the JSF lifecycle, to understand it and to learn about it.

The minimal contents of the test JSF file: test.jsp

<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %>   html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">        xmlns="http://www.w3.org/1999/xhtml">                      </span>Debug JSF lifecycle<span class="codetag" style="font-size: 1em; line-height: 1em; color: rgb(51, 102, 102); ">                                                                     binding="#{myBean.inputComponent}"                     value="#{myBean.inputValue}"                     valueChangeListener="#{myBean.inputChanged}">                      converterId="myConverter" />                      validatorId="myValidator" />                                                       value="submit"                     action="#{myBean.action}" />                                      binding="#{myBean.outputComponent}"                     value="#{myBean.outputValue}" />                                             

The dummy converter: MyConverter.java

package mypackage;  import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import javax.faces.convert.Converter;  public class MyConverter implements Converter {      public Object getAsObject(FacesContext context, UIComponent component, String value) {         System.out.println("MyConverter getAsObject: " + value);         return value;     }      public String getAsString(FacesContext context, UIComponent component, Object value) {         System.out.println("MyConverter getAsString: " + value);         return (String) value;     }  }

The dummy validator: MyValidator.java

package mypackage;  import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import javax.faces.validator.Validator; import javax.faces.validator.ValidatorException;  public class MyValidator implements Validator {      public void validate(FacesContext context, UIComponent component, Object value)         throws ValidatorException     {         System.out.println("MyValidator validate: " + value);     }  }

The backing bean: MyBean.java

package mypackage;  import javax.faces.component.html.HtmlInputText; import javax.faces.component.html.HtmlOutputText; import javax.faces.event.ValueChangeEvent;  public class MyBean {      // Init ----------------------------------------------------------------------------------------      private HtmlInputText inputComponent;     private String inputValue;     private HtmlOutputText outputComponent;     private String outputValue;      // Constructors -------------------------------------------------------------------------------      public MyBean() {         log("constructed");     }      // Actions ------------------------------------------------------------------------------------      public void action() {         outputValue = inputValue;         log("succes");     }      // Getters ------------------------------------------------------------------------------------      public HtmlInputText getInputComponent() {         log(inputComponent);         return inputComponent;     }      public String getInputValue() {         log(inputValue);         return inputValue;     }      public HtmlOutputText getOutputComponent() {         log(outputComponent);         return outputComponent;     }      public String getOutputValue() {         log(outputValue);         return outputValue;     }      // Setters ------------------------------------------------------------------------------------      public void setInputComponent(HtmlInputText inputComponent) {         log(inputComponent);         this.inputComponent = inputComponent;     }      public void setInputValue(String inputValue) {         log(inputValue);         this.inputValue = inputValue;     }      public void setOutputComponent(HtmlOutputText outputComponent) {         log(outputComponent);         this.outputComponent = outputComponent;     }      // Listeners ----------------------------------------------------------------------------------      public void inputChanged(ValueChangeEvent event) {         log(event.getOldValue() + " to " + event.getNewValue());     }      // Helpers ------------------------------------------------------------------------------------      private void log(Object object) {         String methodName = Thread.currentThread().getStackTrace()[2].getMethodName();         System.out.println("MyBean " + methodName + ": " + object);     } } 

The minimal faces configuration: faces-config.xml

     myConverter     mypackage.MyConverter       myValidator     mypackage.MyValidator       myBean     mypackage.MyBean     request 
Back to top

The first call

The first call in a freshly started webapplication with a fresh session should output at least:

START PHASE RESTORE_VIEW 1
END PHASE RESTORE_VIEW 1
START PHASE RENDER_RESPONSE 6
MyBean : constructed
MyBean getInputComponent: null
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean getInputValue: null
MyBean getOutputComponent: null
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
MyBean getOutputValue: null
END PHASE RENDER_RESPONSE 6

1. Restore view.
As the session is fresh, there's no means of any UIViewRoot to restore, so nothing to see here.

2. Apply request values.
This phase is skipped because there is no form submit.

3. Process validations.
This phase is skipped because there is no form submit.

4. Update model values.
This phase is skipped because there is no form submit.

5. Invoke application.
This phase is skipped because there is no form submit.

6. Render response.
The bean is constructed. Behind the scenes a new UIViewRoot is created and stored in the session. If the component binding getters returns precreated components (precreated in e.g. the constructor) and not null, then those will be used, otherwise JSF will create new components. The components will be stored in the UIViewRoot and the bounded components are set in the component bindings. The values to be shown are retrieved from the value binding getters in the backing bean. If the values aren't set yet, they defaults to null. The component bindings are not required by the way. Only use them if you actually need the component in the backing bean for other means than getting/setting the value. In this article they are included just to demonstrate what all happens in the lifecycle.

Back to top

The form submit

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
END PHASE APPLY_REQUEST_VALUES 2
START PHASE PROCESS_VALIDATIONS 3
MyConverter getAsObject: test
MyValidator validate: test
MyBean getInputValue: null
MyBean inputChanged: null to test
END PHASE PROCESS_VALIDATIONS 3
START PHASE UPDATE_MODEL_VALUES 4
MyBean setInputValue: test
END PHASE UPDATE_MODEL_VALUES 4
START PHASE INVOKE_APPLICATION 5
MyBean action: succes
END PHASE INVOKE_APPLICATION 5
START PHASE RENDER_RESPONSE 6
MyBean getInputValue: test
MyConverter getAsString: test
MyBean getOutputValue: test
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
Nothing to see here. Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in the UIViewRoot, for example inputComponent.setSubmittedValue("test").

3. Process validations.
The submitted values are passed through the converter getAsObject() method and validated by the validator. If the conversion and validation succeeds, then the initial input value will be retrieved from the value binding getter and behind the scenes the inputComponent.setValue(submittedValue) and inputComponent.setSubmittedValue(null) will be executed. If the retrieved initial input value differs from the submitted value, then the valueChangeListener method will be invoked.

4. Update model values.
The converted and validated values will now be set in the value binding setters of the backing bean. E.g.myBean.setInputValue(inputComponent.getValue()).

5. Invoke application.
The real processing of the form submission happens here.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean. If a converter is definied, then the value will be passed through the converter getAsString() method and the result will be shown in the form.

Back to top

Add immediate="true" to UIInput only

Extend the h:inputText in the test.jsp with immediate="true":

    ...              binding="#{myBean.inputComponent}"         value="#{myBean.inputValue}"         valueChangeListener="#{myBean.inputChanged}"         immediate="true">     ...

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
MyConverter getAsObject: test
MyValidator validate: test
MyBean getInputValue: null
MyBean inputChanged: null to test
END PHASE APPLY_REQUEST_VALUES 2
START PHASE PROCESS_VALIDATIONS 3
END PHASE PROCESS_VALIDATIONS 3
START PHASE UPDATE_MODEL_VALUES 4
MyBean setInputValue: test
END PHASE UPDATE_MODEL_VALUES 4
START PHASE INVOKE_APPLICATION 5
MyBean action: succes
END PHASE INVOKE_APPLICATION 5
START PHASE RENDER_RESPONSE 6
MyBean getInputValue: test
MyConverter getAsString: test
MyBean getOutputValue: test
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in theUIViewRoot, for example inputComponent.setSubmittedValue("test"). The submitted values are immediately passed through the converter getAsObject() method and validated by the validator. If the conversion and validation succeeds, then the initial input value will be retrieved from the value binding getter and behind the scenes theinputComponent.setValue(submittedValue) and inputComponent.setSubmittedValue(null) will be executed. If the retrieved initial input value differs from the submitted value, then the valueChangeListener method will be invoked. This all happens in this phase instead of the Process validations phase due to the immediate="true" in the h:inputText.

3. Process validations.
Nothing to see here. The conversion and validation is already processed in the Apply request values phase, before the values being put in the components. This is due to the immediate="true" in the h:inputText.

4. Update model values.
The converted and validated values will now be set in the value binding setters of the backing bean. E.g.myBean.setInputValue(inputComponent.getValue()).

5. Invoke application.
The real processing of the form submission happens here.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean. If a converter is definied, then the value will be passed through the converter getAsString() method and the result will be shown in the form.

Note for other components without immediate: any other UIInput components inside the same form which don't haveimmediate="true" set will just continue the lifecycle as usual.

Back to top

Add immediate="true" to UICommand only

Extend the h:commandButton in the test.jsp with immediate="true" (don't forget to remove from h:inputText):

    ...              value="submit"         action="#{myBean.action}"         immediate="true" />     ...

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
MyBean action: succes
END PHASE APPLY_REQUEST_VALUES 2
START PHASE RENDER_RESPONSE 6
MyBean getOutputValue: null
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
The real processing of the form submission happens here. This happens in this phase instead of the Invoke application phase due to the immediate="true" in the h:commandButton. The UIInput components which don't have immediate="true" set will not be converted, validated nor updated, but behind the scenes theinputComponent.setSubmittedValue(submittedValue) will be executed before the action() method will be executed.

3. Process validations.
This phase is skipped due to the immediate="true" in the h:commandButton.

4. Update model values.
This phase is skipped due to the immediate="true" in the h:commandButton.

5. Invoke application.
This phase is skipped due to the immediate="true" in the h:commandButton.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean, expect for the UIInput components which don't have immediate="true" set. Behind the scenes those will be retrieved from the components in the UIViewRoot, e.g. inputComponent.getSubmittedValue().

Note for all components without immediate: as the Update model values phase is skipped, the value bindings aren't been set and the value binding getters will return null. But the values are still available as submitted value of the relevant components in the UIViewRoot. In this case you can retrieve the non-converted and non-validated input value frominputComponent.getSubmittedValue() in the action() method. You could even change it usinginputComponent.setSubmittedValue(newValue) in the action() method.

Back to top

Add immediate="true" to UIInput and UICommand

Extend the h:inputText as well as the h:commandButton in the test.jsp with immediate="true":

    ...              binding="#{myBean.inputComponent}"         value="#{myBean.inputValue}"         valueChangeListener="#{myBean.inputChanged}"         immediate="true">     ...              value="submit"         action="#{myBean.action}"         immediate="true" />     ...

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
MyConverter getAsObject: test
MyValidator validate: test
MyBean getInputValue: null
MyBean inputChanged: null to test
MyBean action: succes
END PHASE APPLY_REQUEST_VALUES 2
START PHASE RENDER_RESPONSE 6
MyConverter getAsString: test
MyBean getOutputValue: null
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in theUIViewRoot, for example inputComponent.setSubmittedValue("test"). The submitted values are immediately passed through the converter getAsObject() method and validated by the validator. If the conversion and validation succeeds, then the initial input value will be retrieved from the value binding getter and behind the scenes theinputComponent.setValue(submittedValue) and inputComponent.setSubmittedValue(null) will be executed. If the retrieved initial input value differs from the submitted value, then the valueChangeListener method will be invoked. This all happens in this phase instead of the Process validations phase due to the immediate="true" in the h:inputText. Finally the real processing of the form submission happens here. This happens in this phase instead of the Invoke application phase due to the immediate="true" in the h:commandButton.

3. Process validations.
This phase is skipped due to the immediate="true" in the h:commandButton.

4. Update model values.
This phase is skipped due to the immediate="true" in the h:commandButton.

5. Invoke application.
This phase is skipped due to the immediate="true" in the h:commandButton.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean. If a converter is definied, then the value will be passed through the converter getAsString() method and the result will be shown in the form.

Note for all components with immediate: as the Update model values phase is skipped, the value bindings aren't been set and the value binding getters will return null. But the values are still available by the relevant components in theUIViewRoot. In this case you can retrieve the input value from inputComponent.getValue() in the action() method. The new input value is also available by the ValueChangeEvent in the inputChanged() method. You could even change it usinginputComponent.setValue(newValue) in the action() method.

Note for other components without immediate: any other UIInput components inside the same form which don't haveimmediate="true" set will not be converted, validated nor updated, but behind the scenes theinputComponent.setSubmittedValue(submittedValue) will be executed before the action() method will be executed. You can retrieve the non-converted and non-validated input value from inputComponent.getSubmittedValue() in the action()method. You could even change it using inputComponent.setSubmittedValue(newValue) in the action() method.

Back to top

Conversion error

Let's see what happens if a conversion error will occur. Change the getAsObject() method of MyConverter.java as follows (and remove the immediate="true" from the test.jsp file):

package mypackage;  import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import javax.faces.convert.Converter; import javax.faces.convert.ConverterException;  public class MyConverter implements Converter {      public Object getAsObject(FacesContext context, UIComponent component, String value) {         System.out.println("MyConverter getAsObject: " + value);         throw new ConverterException("Conversion failed.");     }      ... }

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
END PHASE APPLY_REQUEST_VALUES 2
START PHASE PROCESS_VALIDATIONS 3
MyConverter getAsObject: test
END PHASE PROCESS_VALIDATIONS 3
START PHASE RENDER_RESPONSE 6
MyBean getOutputValue: null
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
Nothing to see here. Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in the UIViewRoot, for example inputComponent.setSubmittedValue("test").

3. Process validations.
The submitted values are passed through the converter getAsObject() method, where a ConverterException is thrown. The validator and the valueChangeListener are bypassed. Also the inputComponent.setValue(submittedValue) won't take place. The lifecycle will proceed to the Render response phase immediately.

4. Update model values.
This phase is skipped due to the ConverterException.

5. Invoke application.
This phase is skipped due to the ConverterException.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean, expecting the values for which a ConverterException has occurred. Behind the scenes those will be retrieved from the components in the UIViewRoot, e.g.inputComponent.getSubmittedValue().

Note: any other UIInput components inside the same form which don't throw a ConverterException will continue the lifecycleas usual, only the invoke application phase will still be skipped.

Back to top

Validation error

Let's see what happens if a validation error will occur. Change the validate() method of MyValidator.java as follows (and remove the immediate="true" from the test.jsp file and revert MyConverter.java back to original):

package mypackage;  import javax.faces.application.FacesMessage; import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import javax.faces.validator.Validator; import javax.faces.validator.ValidatorException;  public class MyValidator implements Validator {      public void validate(FacesContext context, UIComponent component, Object value)         throws ValidatorException     {         System.out.println("MyValidator validate: " + value);         throw new ValidatorException(new FacesMessage("Validation failed."));     }  }

The form submit with the value "test" entered should output at least:

START PHASE RESTORE_VIEW 1
MyBean : constructed
MyBean setInputComponent: javax.faces.component.html.HtmlInputText@2a9fca57
MyBean setOutputComponent: javax.faces.component.html.HtmlOutputText@13bbca56
END PHASE RESTORE_VIEW 1
START PHASE APPLY_REQUEST_VALUES 2
END PHASE APPLY_REQUEST_VALUES 2
START PHASE PROCESS_VALIDATIONS 3
MyConverter getAsObject: test
MyValidator validate: test
END PHASE PROCESS_VALIDATIONS 3
START PHASE RENDER_RESPONSE 6
MyBean getOutputValue: null
END PHASE RENDER_RESPONSE 6

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.

2. Apply request values.
Nothing to see here. Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in the UIViewRoot, for example inputComponent.setSubmittedValue("test").

3. Process validations.
The values are retrieved as objects from the components, passed through the converter getAsObject() method and validated by the validator, where a ValidatorException is thrown. The valueChangeListener is bypassed. Also theinputComponent.setValue(submittedValue) won't take place. The lifecycle will proceed to the Render response phase immediately.

4. Update model values.
This phase is skipped due to the ValidatorException.

5. Invoke application.
This phase is skipped due to the ValidatorException.

6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean, expect of the values for which a ValidatorException has occurred. Behind the scenes those will be retrieved from the components in the UIViewRoot, e.g.inputComponent.getSubmittedValue().

Note: any other UIInput components inside the same form which don't throw a ValidatorException will continue the lifecycleas usual, only the invoke application phase will still be skipped.

Back to top

Okay, when should I use the immediate attribute?

If it isn't entirely clear yet, here's a summary, complete with real world use examples when they may be beneficial:

  • If set in UIInput(s) only, the process validations phase will be taken place in apply request values phase instead. Use this to prioritize validation for the UIInput component(s) in question. When validation/conversion fails for any of them, the non-immediate components won't be validated/converted.
  • If set in UICommand only, the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s). Use this to skip the entire processing of the form. E.g. "Cancel" or "Back" button.
  • If set in both UIInput and UICommand components, the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s) which does not have this attribute set. Use this to skip the processing of the entire form expect for certain fields (with immediate). E.g. "Password forgotten" button in a login form with a required and immediate username field and a required but non-immediate password field.