Get to Know JSF: An Easy and Straightforward a Jakarta Framework

DZone 's Guide to

Get to Know JSF: An Easy and Straightforward a Jakarta Framework

In this article, we discuss how and why we should use Java Server Faces (JSF) to move an application to the cloud.

· Java Zone ·
Free Resource

Developing web systems is a reality in the current market, and the Jakarta Server Faces framework is a standard Jakarta EE option to solve this type of problem. One of the characteristics of JSF is to work in a way oriented towards screen components and their events (for example, clicks). In this way, we can associate these components with different aspects of our system, such as the execution of business operations, value conversions, field validations, etc. In this article, we'll talk about this JSF and how to move this application to the cloud with Platform.sh.

To celebrate the new year, let's create a small wish list in Java with Jakarta EE technologies. In the front end, we'll use Java Server Faces (JSF), a Java-based web application framework that simplifies the development and integration of web-based user interfaces with several already-made components. To store the list, let's use MongoDB.

Jakarta Server Faces defines an MVC framework for building user interfaces for web applications, including UI components, state management, event handling, input validation, page navigation, and support for internationalization and accessibility. It is MVC easy.

As with any Maven project, the first step is to define the dependencies that the application requires. On this JSF and MongoDB application on the Jakarta EE stack, we'll use JSF, Jakarta NoSQL, and Primefaces. Primefaces is an open-source user interface (UI) component library for JSF-based applications. 


The next step is the MongoDB integration; we won't go further because we have two articles about the introduction to Jakarta NoSQL one about the API and second what's Jakarta NoSQL and the introduction with cloud native.


The entity and the database integration both are done. The next step is the controller. JSF has a Managed Bean that is a regular Java Bean class registered with JSF. In other words, the Managed Bean is a Java bean managed by the JSF framework. Managed Bean contains the getter and setter methods, business logic, or even a backing bean (a bean contains all the HTML form value).


The bean has the @Model annotation to map this map to be ready to use on the JSF page and has the request scope. This will enable us to use this class as wishBean.  JSF has several scopes in its managed beans such as:

  • @RequestScoped: Bean lives as long as the HTTP request-response lives. It gets created upon an HTTP request and gets destroyed when the HTTP response associated with the HTTP request is finished.

  • @ViewScoped: Bean lives as long as the user is interacting with the same JSF view in the browser window/tab. It gets created upon an HTTP request and gets destroyed once the user postbacks to a different view.

  • @SessionScoped: Bean lives as long as the HTTP session lives. It gets created upon the first HTTP request involving this bean in the session and gets destroyed when the HTTP session is invalidated.
  • @ApplicationScoped: Bean lives as long as the web application lives. It gets created upon the first HTTP request involving this bean in the application (or when the web application starts up and the eager=true attribute is set in @ManagedBean) and gets destroyed when the web application shuts down.

The XHML page shows how easy it is to integrate action with Ajax using Java classes mapped by JSF/CDI annotations. On the JSF, we have Ajax natively, so we can use the update attribute without a strong effort on the frontend (e.g., to list elements, there are the  #{wishBean.wishes}  where it calls the method getWishes in the class WishBean.

Platform.sh Structure

The Java application is ready to go! The next step is to set the Platform.sh files required to manage and deploy the application. In our first Java post, we took a deep dive into each detail of these three files:

  • One router (.platform/routes.yaml). Platform.sh allows you to define the routes.

  • Zero or more service containers (.platform/services.yaml). Platform.sh allows you to completely define and configure the topology and services you want to use on your project.

  • One or more application containers (.platform.app.yaml). You control your application and the way it will be built and deployed on Platform.sh via a single configuration file.

We'll change the services.yaml to add MongoDB.


We'll set the application file.


Move the Project to a Github Repository

We’ll create a Git repository and Platform.sh account in three easy steps:

  1. Create a GitHub repository.

  2. Create a Platform.sh project.

  3. Integrate Platform.sh and GitHub.

This integration allows us to once we push the code to the master branch on the Github repository, Platform.sh will generate the application automatically to us.

In this article, we discussed JSF and how it is easy to integrate Java applications on Jakarta EE. Software that has CI/CD has a great guarantee of quality, is best practice, and makes and Platform.sh a perfect fit for your next cloud project.

Source: https://github.com/soujava/wishlist.

jakarta, jakarta nosql, java, jnosql, mongodb, nosql, saas

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}