...

Frequently Asked Questions

...

Note that in addition to this FAQ, there are a number of "how-to" guides on the MyFaces wiki home page that address common issues. Table of ContentsmaxLevel

4minLevel2

What is MyFaces?

MyFaces is a family of projects related to the JavaServer Faces (JSF) specification published as part of the Java Community Process. The "core" project is an implementation of that specification. Other MyFaces projects implement related specifications (eg the Portlet Bridge), or add features to any JSF implementation (not just the Myfaces Core).

...

If you want to serialize the list within the !DataModel along with the managed bean, then do this:

...

Why are my dates displaying the wrong day/time?

...

You can control the timezone used by the conversion by attaching an explicit converter:

...

or

...

...

where #{bean.timeZone} returns either a string id, or a TimeZone instance.

The MyFaces commons converters project contains a custom converter tag which is like f:convertDateTime, but defaults to using the timezone of the server:

...

...

Alternatively you register your own converter to override the standard converter, causing your custom code to be applied by default to all date->string conversions.

...

In some cases, a component in a JSP page needs to reference another component by id. One common example is the tomahawk t:dataScroller component. This is fine when the referencing component is later in the page than the one it refers to. But when the components are in the wrong order, an error is reported.

...

...

When using JSP, creating and rendering of components is done in a single pass through the JSP page. This means that when the dataScroller is rendered, the dataTable it refers to has not yet been created, causing an error message about "cannot find UIData" to be displayed. Other components that refer to some associated component using a "for" attribute or similar mechanism will have this problem too.

This can be resolved by wrapping the components in a parent component that "renders its children". Such components cause their nested components to be processed in two passes (create then render):

...

...

This does have a few minor drawbacks. In JSF 1.1, components that render their children interact badly with nested "template text" and non-JSF JSP tags. Avoid non-JSF JSP tags within such components, and wrap any "template text" in f:verbatim tags to resolve this problem.

...

• defining a setter method on the bean, eg "public void setInitialized(boolean state)"
• defining this as the last managed property for the bean:

...

The JSF spec requires that managed properties are initialised in the order they are declared, so the setInitialized method will be called only after all other properties have been set.

...

The JSF specification requires any JSF implementation to automatically load /WEB-INF/faces-config.xml at startup. There is consequently no need for the following context parameter:

...

...

Putting this context parameter in your deployment descriptor will force any JSF implementation to load the configuration twice, therefore registering each phase listener twice.

...

Action listeners and actions are not invoked when the action source ( h:commandLink, h:commandButton ) is not rendered. When our action sources are on a dataTable, and the value attribute of the dataTable points to a request scoped data source, the action source just isn't rendered on a subsequent request.

...

The action source ( h:commandLink, h:commandButton ), is not rendered because the data source does not exist during a subsequent request ( it was garbage collected after the first response was completed).

To solve this problem, use t:saveState or put the request scoped backing bean in session scope.

...

t:saveState is preffered over a session scoped solution.

...

NullPointerException in adf faces at the start of the render phase OR rendering warnings

...

Make sure your FaceletViewHandler is commented out and the default render kit of ADF faces defined in faces-config.xml oracle.adf.core (Note that the ADF faces implementation ensures non-ADF components still get rendered in the normal way so it can safely co-exist with other JSF components) ..and your web.xml contains these lines for ADF faces oracle.adf.view.faces.ALTERNATE_VIEW_HANDLER com.sun.facelets.FaceletViewHandler AdfFacesFilter oracle.adf.view.faces.webapp.AdfFacesFilter AdfFacesFilter FacesServlet

...

MyFaces 1.1.4 and earlier did not correctly implement the select components. Although the behavior was nice, the components were not supposed to convert the values from the UISelectItems. For example, in 1.1.4 this would have worked:

...

The reason this used to work is that the code in the past used the converter on the select one menu component to convert the value from the select item. According to the JSF specification, this is not supposed to be done. Therefore, it is important that the converted value from the selectOneMenu is identical (passes the equals function test) to the itemValue from one of the select items. Therefore, for the example above, itemValue must be an integer value, not a string with a number in it.

If you want the old behavior, I suggest creating a custom selectItem component that converts the value using the converter from the input control. Here is the code:

...

...

Then just register this new component in the standard JSF way.

...

...