Mojarra 5.0

Eclipse's implementation of the Jakarta Faces 5.0 specification

• Mojarra 5.0 - this branch, under development
• Mojarra 4.1 - stable release
• Mojarra 4.0 - stable release
• Mojarra 3.0 - legacy release
• Mojarra 2.3 - legacy release

For support on Mojarra 2.3 and earlier please contact your vendor for support (RedHat, IBM, Oracle, Omnifish, Payara, etceteras)

Minimum Requirements

• Java 17
• Jakarta Servlet 6.2
• Jakarta Expression Language 6.1
• Jakarta CDI 5.0
• Jakarta Web Socket 2.3 (optional, only when <f:websocket> is used)
• Jakarta JSON Processing 2.1 (optional, only when <f:websocket> is used)
• Jakarta Validation 4.0 (optional, only when <f:validateBean> or <f:validateWholeBean> is used)

Installation

Depending on the server used, Jakarta Faces may already be built-in (full fledged Jakarta EE containers such as WildFly, JBoss EAP, TomEE, Payara, GlassFish, Liberty, etc.), or not (barebones Jakarta Server Pages/Jakarta Servlet containers such as Tomcat, Jetty, etc.). If the server doesn't ship with Jakarta Faces built-in, then you need to manually install Jakarta Faces 4.0 along with CDI 4.0+, Jakarta JSON Processing 2.0+ and Jakarta Standard Tag Library 2.0+ as those Jakarta Servlet containers usually also don't even ship with those Jakarta Faces dependencies.

Non-Maven

In case you're manually carrying around JARs:

• Jakarta EE containers (WildFly, JBoss EAP, TomEE, Payara, GlassFish, Liberty, etc)

  You don't need to add any JARs to /WEB-INF/lib!

• Jakarta Servlet containers (Tomcat, Jetty, etc)

  Add below JARs to /WEB-INF/lib:

  • jakarta.faces-api.5.0.x.jar
  • mojarra.5.0.x.jar
  • weld-servlet-shaded-7.0.x.Final.jar
  • jakarta.json-api-2.1.x.jar (optional, only when <f:websocket> is used)
  • parsson-1.1.x.jar (optional, only when <f:websocket> is used)
  • jakarta.validation-api-4.0.x.jar (optional, only when <f:validateBean|validateWholeBean> is used)
  • hibernate-validator-9.1.x.Final.jar (optional, only when <f:validateBean|validateWholeBean> is used)

  Substitute x with latest version number available.

Maven

In case you're using Maven, you can find below the necessary coordinates:

• Java EE containers (WildFly, JBoss EAP, TomEE, Payara, GlassFish, Liberty, etc)

  <dependency>
     <groupId>jakarta.platform</groupId>
     <artifactId>jakarta.jakartaee-api</artifactId>
     <version>12.0.0</version>
     <scope>provided</scope>
  </dependency>

• Servletcontainers (Tomcat, Jetty, etc)

  <dependency>
      <groupId>org.glassfish</groupId>
      <artifactId>mojarra</artifactId>
      <version><!-- Use latest 5.0.x version. --></version>
  </dependency>
  <dependency>
      <groupId>org.jboss.weld.servlet</groupId>
      <artifactId>weld-servlet-shaded</artifactId>
      <version><!-- Use latest 7.0.x version. --></version>
  </dependency>
  <dependency> <!-- Optional, only when <f:websocket> is used. -->
      <groupId>org.eclipse.parsson</groupId>
      <artifactId>parsson</artifactId>
      <version><!-- Use latest 1.1.x version. --></version>
  </dependency>
  <dependency> <!-- Optional, only when <f:validateBean> or <f:validateWholeBean> is used. -->
      <groupId>org.hibernate.validator</groupId>
      <artifactId>hibernate-validator</artifactId>
      <version><!-- Use latest 9.1.x version. --></version>
  </dependency>

You can check org.glassfish:mojarra repository to find the latest Mojarra 5.0.x version.

Testing

Since Mojarra 4, tests have been moved to the Faces project.

Hello World Example

We assume that you already know how to create an empty Maven WAR Project or Dynamic Web Project in your favourite IDE with a CDI 4.0+ compatible /WEB-INF/beans.xml deployment descriptor file (which can be kept fully empty). Don't forget to add JARs or configure pom.xml if necessary, as instructed in previous chapter.

Controller

Optionally, register the FacesServlet in a Servlet 6.0+ compatible deployment descriptor file /WEB-INF/web.xml as below:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="https://jakarta.ee/xml/ns/jakartaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_1.xsd"
    version="6.1"
>
    <servlet>
        <servlet-name>facesServlet</servlet-name>
        <servlet-class>jakarta.faces.webapp.FacesServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>facesServlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>
</web-app>

Noted should be that Jakarta Faces is already "implicitly" registered and mapped on *.xhtml, *.jsf, *.faces and /faces/* when running on a Jakarta Servlet container. This will be overridden altogether when explicitly registering as above. The *.xhtml URL pattern is preferred over above for security and clarity reasons. When you don't explicitly map it on *.xhtml, then people can still access Faces pages using *.jsf, *.faces or /faces/* URL patterns. This is not nice for SEO as Faces by design doesn't 301-redirect them to a single mapping.

The Faces deployment descriptor file /WEB-INF/faces-config.xml is fully optional.

<?xml version="1.0" encoding="UTF-8"?>
<faces-config
    xmlns="https://jakarta.ee/xml/ns/jakartaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-facesconfig_4_1.xsd"
    version="4.1"
>
    <!-- Put any faces config here. -->
</faces-config>

Model

Then create a backing bean class as below:

package com.example;

import jakarta.enterprise.context.RequestScoped;
import jakarta.inject.Named;

@Named
@RequestScoped
public class Hello {

    private String name;
    private String message;

    public void createMessage() {
        message = "Hello, " + name + "!";
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getMessage() {
        return message;
    }

}

Noted should be that in reality in the average Jakarta EE application the above "model" is further breakdown into a Jakarta Persistence entity, a Jakarta Enterprise Beans service and a smaller backing bean. The Jakarta Persistence entity and Jakarta Enterprise Beans service then basically act as a true "model" and the backing bean becomes a "controller" for that model. This may in first place be confusing to starters, but it all depends on the point of view. See also What components are MVC in Faces MVC framework? and Faces Controller, Service and DAO.

View

Finally create a Facelets file /hello.xhtml as below:

<!DOCTYPE html>
<html lang="en"
    xmlns:f="jakarta.faces.core"
    xmlns:h="jakarta.faces.html">
    <h:head>
        <title>Hello, World!</title>
    </h:head>
    <h:body>
        <h:form>
            <h:outputLabel for="name" value="Enter your name" required="true" />
            <h:inputText id="name" value="#{hello.name}" />
            <h:message for="name" />
            <br />
            <h:commandButton value="Say hello" action="#{hello.createMessage}">
                <f:ajax execute="@form" render="@form" />
            </h:commandButton>
            <br />
            #{hello.message}
        </h:form>
    </h:body>
</html>

Start the server and open it by http://localhost:8080/contextname/hello.xhtml.

Activating CDI in Jakarta Faces 4.1

CDI is activated by default in Jakarta Faces 4.1 and can´t be deactivated.
It´s not anymore required to add @FacesConfig to a CDI managed bean to accomplish this. As of Jakarta Faces 4.0 @FacesConfig still removes the need to explicitly add a FacesServlet entry to web.xml.

Building and Contributing

Instructions for checking out the source, building from source, importing into an IDE, and submitting pull requests are available in DEVELOPERS.md.

Resources

• Faces 5.0 Specification
• Faces 5.0 API documentation
• Faces 5.0 VDL documentation
• Faces 5.0 JS documentation