Category Archives: JSF 2.X

JavaServer Pages 2.0

HoneyBee Portal For Naturopathy. A Java EE Cloud Application

HoneyBee Portal for Naturopathy

A Starting version of a new open source Java EE web portal has come to life, thanks to PaaS offering from Red Hat. The application is pure Java EE work, running the following environment:
  • View Framework: JavaServer Faces (JSF) as View Framework 2.1.
  • Database: Oracle MySQL 5.5.
  • Application Container: JBoss AS 7.1.1
  • JSF Facelets Library: PrimeFaces 3.5 & PrimeFaces Mobile 0.9.
  • Compatible Browsers: Mozilla Firefox +3 & Google Chrome. (No Internet Explorer).
  • Build Automation System: Maven 3
  • Persistence Provider: JPA through Hibernate 4.
  • Business Layer: EJB 3 & Faces Managed Beans.
  • Testing framework: Arquillian through JUnit
  • Code Source Host: GitHub
  • Operating System: Ubuntu Linux 13.04.
  • Cloud Host: Paas OpenShift
This application was designed with love and passion. It’s multiligual and should let the user interact with a database of Naturopathy. The common user can browse natural prescriptions, plants.. Using human body parts, cure virtues, types of illnesses or defects, computes his/her body mass index and determine somatotype ….
People interested in contributing either technically or functionally to the application are welcome. Nevertheless, content is being filled continuously, and updates are not regular, so please do not expect to find almost everything related to Naturopathy. If you have time to contribute, please feel free to contact us.

Adoption of Java Web Frameworks & Library Components Statistics

A recent study bu OIO Compass (April 2012) provides the following:

jsf 2.0

Duke with JSF 2

The selected web frameworks

Caveat: The study participants have indicated a 73% interest with the selection of the framework to be satisfied.

The spectrum of the finally chosen web framework is set up pretty wide. The most common decision was taken in connection with the JSF specification, a total of 32% of participants chose JSF.

Employed Web Framework

Figure: Employed Web Framework

In second place come Spring MVC and GWT with 16%.

The evidence today than market rates prestigious web frameworks in the Java environment JSF, Spring MVC and GWT 62% of the decisions. Grails, Groovy-based framework is one, with 16% in the 4th Place, although the developers have to learn a new language (Groovy).

Interestingly enough, with Spring MVC and 32% of the Grails framework used in the home SpringSource and VMware.

The fragmentation in the Java web framework environment is even more apparent when the are usually brought in connection with JSF components used in libraries.

Much as 35% of participants who have opted for the use of JSF have also decided to develop their own UI components.

JSF component libraries

Figure: JSF component libraries


New Features of JavaServer Faces 2.2 in progress

Updated First May 2012.

JavaServer Faces 2.X

JavaServer Faces 2.X


    <f:viewAction action="#{someBean.someAction}" />

NAVIGATIONFinally, the Flow scope (Faces Flow) is here and is a big step towards dependency
on CDI. In JSF 2.0, one used sessionScoped beans to pass information through pages
or the ConversationScoped beans using CDI, but that was not enough complete as
the Spring Web Flowfor example.

public class SomBean { // ... }
<faces-config version="2.2" xmlns=""
<html xmlns=""
        <j:faces-flow-definition id="flow"/>


– Adding support for Ajax requests Queue control
– Adding support for Ajax file upload component

<h:form prependId="false" enctype="multipart/form-data">
    <!-- The new regular file upload component -->
    <h:inputFile id="fileUpload" value="#{someBean.file}" />
    <h:commandButton value="Upload" />


In JSF 2.2 injection will be possible in:
converters, validators, components, behaviors and much more artifacts.

Without the need to configure or declare anything else, this component can now be used on a JSF 2.2 Facelet as follows:

@FacesComponent(value="components.CustomComponent", createTag=true)
public class CustomComponent extends UIComponentBase {
    public String getFamily() {
        return "my.custom.component";
    public void encodeBegin(FacesContext context) throws IOException {

        String value = (String) getAttributes().get("value");

        if (value != null) {
            ResponseWriter writer = context.getResponseWriter();


<html xmlns=""
xmlns:test="" >
<test:customComponent value="test"/>

The presence of that annotation on a class automatically registers it as a Facelets resource resolver.
If a resolver is specified in both XML and via an annotation, the XML overrides the annotation as per the usual Java EE conventions.
If multiple annotated classes are found, the first one encountered is used and a warning is logged.
Before we had to specify a name for a FacesComponent like this:

public class Bar extends UIComponentBase {
    // ...

In JSF 2.2 the name can now be omitted for components, converters and validators as well, so the code shown above can become:

public class Bar extends UIComponentBase {
    // ...


Cross Site Request Forgery is an attack that lets users unknowingly do a request to a site where they are supposed to be logged-in, that has some side-effect that is most likely in some way beneficial to the attacker. GET based requests are most obvious here, but POST requests are just as vulnerable. JSF seems to have some implicit protection against this when state is saved on the server, since a post-back must contain a valid javax.faces.ViewStatehidden parameter. Contrary to earlier versions, this value seems sufficiently random in modern JSF implementations. Nevertheless, JSF 2.2 will contain additional/even stricter protection against this. Among others client state encryption is now on by default and there’s a token parameter for protection of non-postback views.


JSF 2.2 will introduce a javax.faces.model.CollectionDataModel in which UIData wraps an incoming value if it’s of type Collection. Collection is one of the last types being checked, so if the incoming value is a List the ListDataModeltakes precedence. The following are now the supported types:
  • null (becomes empty list)
  • javax.faces.model.DataModel
  • java.util.List
  • java.lang.Object[]
  • java.sql.ResultSet
  • javax.servlet.jsp.jstl.sql.Result
  • java.util.Collection new!
  • java.lang.Object (becomes ScalarDataModel)
Two different aspects of this will be supported in JSF 2.2:

  • Identification of an individual window: the Window Id
  • API and life-cyle awareness of the window concept

The programmer can configure the preferred method in web.xml via a context parameter:


The current draft implementation supports only field and none which is the default. Additional anticipated values are script and url.


Who’s using JSF?

Have you ever wondered what brands / institutions and/or businesses are using JSF? Check this pages for links:

Locale managed Bean in JSF 2.0

package beans;

 * @version 1.0
 * @author Med
import java.util.Locale;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.context.FacesContext;

public class LocaleBean {

     * The Locale value is retrieved from the JSF view root.
    private Locale locale = FacesContext.getCurrentInstance().getViewRoot().getLocale();

     * @return the locale
    public Locale getLocale() {
        return locale;

     * @return The language from the locale
    public String getLanguage() {
        return locale.getLanguage();

     * Setter for the locale langue | It sets the locale that takes language as a parameter to the JSF View Root
     * @param language
    public void setLanguage(String language) {
        locale = new Locale(language);