THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
Frequently Asked Questions
NOTE: THE DOCUMENTATION HAS BEEN MOVED TO http://myfaces.apache.org/wiki/core/faq.html
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.
...
42
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).
...
Source for released versions of MyFaces Core can be found here:
- http://svn.apache.org/repos/asf/myfaces/core/tags
- http://svn.apache.org/repos/asf/myfaces/shared/tags
Note that MyFaces Core 1.1.x releases (ie implementations of JSF 1.1) include code from the shared project versions 2.0.x. MyFaces Core 1.2.x releases (ie implementations of JSF 1.2) include code from the shared project versions 3.0.x.
Since version 2.0.8 and 2.1.2, shared code was bundled as a module in core, so you only need to checkout its related tags folder.
Source for Tomahawk
- http://svn.apache.org/repos/asf/myfaces/tomahawk/tags/
- http://svn.apache.org/repos/asf/myfaces/shared/tags/ (choose 2.0.x tags)
You can also find builds at this location:
http://people.apache.org/builds/myfaces/
Sources jars usable in IDEs are available from the maven2 repository directories:
- http://www.ibiblio.org/maven2/org/apache/myfaces/core/
- http://www.ibiblio.org/maven2/org/apache/myfaces/shared/
Where can I download a sandbox jar?
Binaries of not-yet-released code can be grabbed from the maven build repositories.
For example, the sandbox jar is available beneath here:
- https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/tomahawk/tomahawk-sandbox20/
- https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/tomahawk/tomahawk-sandbox12/
- https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/tomahawk/tomahawk-sandbox/
What is the "shared" project?
...
The shared code has release numbers that are separate from the release numbers of projects that use it. For example,
http://svn.apache.org/repos/asf/myfaces/tomahawk/tags/1_1_3/core/pom.xml
shows that tomahawk 1.1.3 has a dependency on version 2.0.2 of the shared project.
...
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.
In future versions of JSF, it may be possible to annotate managed bean methods with @!PostConstruct and @!PreDestroy to perform this functionality. See:
"My PhaseListener is called twice"
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.
...
Update to the latest Tomahawk jar from http://myfaces.apache.org/download.html
Using the tomahawk you get java.lang.NoClassDefFoundError: org/apache/commons/lang/builder/HashCodeBuilder
Download the latest jakarta commons jars (inside the MyFaces Core 1.1.3 or later distribution) from http://myfaces.apache.org/download.html
WARNING: The AdfFacesFilter has not been installed. ADF Faces requires this filter for proper execution.
...
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.
...
Overview
Content Tools
Apps