Versions Compared

Old Version 19

changes.mady.by.user Leonardo Uribe

Saved on

compared with

New Version Current

changes.mady.by.user Leonardo Uribe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

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).

...

JSF FAQ

Are there any other FAQ sites for JSF?

...

One solution is to use navigation rules marked with <redirect/>. Then, instead of performing an internal forward to the new page, an http redirect command is sent to the browser, causing it to then fetch the new page. This is less efficient, however, as the browser now has to make a second request to get its content, instead of just getting the content immediately as a response to its original form posting. Another serious issue is that because the fetch of page B is in a separate request, it is impossible for page A to pass any data to page B via request-scoped variables. Using request-scoped variables for this purpose is quite convenient and therefore quite common.

Myfaces FAQ

I have a problem. Should I open a JIRA issue on it or ask about it on the mailing list?

Please ask all questions on the !MyFaces users list.

Why should I use MyFaces Core?

"... Every Java EE application server comes with a bundled JSF implementation. Often the reference implementation (RI), known as "Mojarra", is used for this. However, you can bundle an alternative JSF implementation to be used with your project. This way, you can use MyFaces Core as JSF implementation on every Java EE application server. One of the benefits of using MyFaces Core is that it generates more informative logging, which can be helpful while debugging. If you're looking for an application server that uses MyFaces Core by default, you should take a look at Apache Geronimo..." Thanks to Bart Kummel for provide this text from its book Apache MyFaces 1.2 Web Application Development

Other reason why choose MyFaces core are:

  • Community over code: MyFaces community counts with a lot of folks with outstanding knowledge on JSF. Suscribe to user and dev mailing lists are the best way to know what's going on, receive feedback and know other people interested in JSF. This is an important consideration, because sometimes you can find a bug or need to ask something to somebody about JSF.
  • Innovation happens on MyFaces: MyFaces is not just a JSF implementation, it host other projects (Trinidad,Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) that provides additional functionality not provided by JSF implementation itself.
  • MyFaces Core generates code using myfaces-builder-plugin: these project is a maven plugin that with myfaces-builder-annotations provides a jsf development kit to create multiple artifacts (components, converters, validators, client behaviors) and handle all documentation related in an easier way, minimizing the number of files you need to handle. It uses java annotations to feed all related information, and each myfaces jar using this tool has a myfaces-metadata.xml which contains all meta-information required to build each bundle. This tool can read composite component definitions and build an integrated documentation with your normal components, converters or validators.
  • MyFaces uses Maven, so edit the code or rebuild it is as simple as open any maven project with your IDE. Note that most IDEs has built-in support for maven.
  • MyFaces Core is "OSGi" friendly: It provides some SPI interfaces to deal with special setups, when you need core control over classloading. A lot of good stuff has been put in this area.
  • MyFaces Core is tested everyday against MyFaces UI component libraries and Add-ons/Extensions. Many of these projects are compatible with both MyFaces and Mojarra (because they are build on top of JSF standard), but you should note that those projects helps MyFaces Core to keep code in good shape, because all those projects test against MyFaces Core, and if there is a bug, it is handled more quickly (because everything is handled "in home").

For more technical reasons why choose MyFaces core take a look at this blog.

I have a problem. Should I open a JIRA issue on it or ask about it on the mailing list?

Please ask all questions on the !MyFaces users list.

As as guideline, only create a JIRA issue if

...

Source for released versions of MyFaces Core can be found here:

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

You can also find builds at this location:
http://people.apache.org/builds/myfaces/Image Removed

Sources jars usable in IDEs are available from the maven2 repository directories:

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:

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.xmlImage Removed
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.htmlImage Removed

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.htmlImage Removed

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.

...