Jakarta Faces

• has a lot of settings available that can be configured via <context-param> entries in web.xml
• The default configuration is okay to start with, but let's instructs Jakarta Faces to interpret empty string submitted values as null in the model right from the beginning.
• This is achieved by adding the following section to the web.xml

<context-param> 
       <param-name>
              jakarta.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
      </param-name>
      <param-value>true</param-value> 
</context-param>

Creating New Maven Project in Eclipse

Configuring POM

• Specify packaging in war to indicates the project is a web project.
• Set UTF-8 encoding that the source files are in and with which the (reporting) output files should be generated.
• Set Compiler to 17 for Java version used in the .java source files and the byte code output in the .class files as Maven defaults to the oldest version possible.
• Set failOnMissingWebXml property to false, Older versions of Jakarta EE required the /WEB-INF/web.xml to be present
• Add dependency jakarta.platform:jakarta.jakartaee-api:10.0.0 provided which also makes sure all Jakarta EE types like FacesServlet, @Named, and @Entity are known to the compiler.
• Add plug-in maven-war-plugin:3.3.2 to overrides the Eclipse built-in default version of the Maven WAR plug-in. It is not necessary if you’re not facing the error message Could not initialize class WebappStructureSerializer in your Eclipse version.

Instruct Eclipse to Generate Deployment Descriptor Files

• Right-click the project in Project Explorer view and choose Properties and then open the Project Facets section
• The Servlet API is represented by the Dynamic Web Module entry and needs to be set to version 6.0, which matches the Jakarta EE 10 specification.
• The Jakarta Faces and Jakarta Persistence entries need to be selected and set to versions 4.0 and 3.1, respectively, matching the Jakarta EE 10 specification.
• While at it, you also need to double-check if the version of the Java facet is indeed 17 or whatever version is set in pom.xml
• If for your version of Eclipse the highest available versions are Servlet 5.0, Faces 2.3, and Persistence 2.2, it's not a big problem
• see warning bar near the bottom, Eclipse requires further configuration. This concerns the newly selected Jakarta Faces and Jakarta Persistence facets.
• Click the link, you get to see the Modify Faceted Project wizard.
• For Jakarta Persistence facet, choose Disable Library Configuration option in the Jakarta Persistence implementation field to instruct Eclipse that the Jakarta Persistence implementation is already provided by the target runtime.
• We’re going to use the WildFly-provided Hibernate as the actual Jakarta Persistence implementation, which supports automatically discovering of @Entity annotated classes. To instruct Eclipse to do the same, choose the Discover annotated classes automatically option in Persistent class management field
• Next step configure the Jakarta Faces capabilities. Also here, instruct Eclipse that the Jakarta Faces implementation is already provided by the target runtime. Choose Disable Library Configuration option in the Jakarta Faces Implementation Library field.
• Rename the servlet name of the FacesServlet to match the fictive instance variable name: facesServlet. Last, change the URL mapping pattern from the Jurassic /faces/* to the modern *.xhtml.
• Now, finish and apply all the wizards and dialogs.

NOTE

Unfortunately, the Jakarta Persistence plug-in of the current Eclipse version only puts the generated persistence.xml in the wrong place. The plug-in blindly puts the generated persistence.xml file in the src/main/java/META-INF folder which is wrong. Move it into src/main/resources/META-INF to conform to the rules of a Maven project.

Installing H2

• H2 is an in-memory SQL database.
• It’s an embedded database useful for quickly modeling and testing Jakarta Persistence entities, certainly in combination with autogenerated SQL tables based on Jakarta Persistence entities.
• Add H2 to your web application project by adding the following dependency to the <dependencies> section of the pom.xml.
• The JDBC (Java Database Connectivity) driver is also provided by this dependency.

<dependency> 
    <groupId>com.h2database</groupId> 
    <artifactId>h2</artifactId> 
    <version>2.1.210</version>
</dependency>

Configuring DataSource

• To be able to interact with an SQL database, we need to configure data source in the web application project by adding the following section to the web.xml.

<data-source>
    <name>java:global/DataSourceName</name> 
    <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
    <url>jdbc:h2:mem:test;MODE=LEGACY;DB_CLOSE_DELAY=-1</url>                                         
</data-source>

• The <name> of the data source represents the JNDI (Java Naming and Directory Interface) name.
• The java:global/ part is mandatory. The DataSourceName part is free to your choice.
• It’s the one that ultimately needs to be registered in the persistence.xml later on.
• The <class-name> represents the fully qualified name of the javax.sql.DataSource implementation of the JDBC driver.
• The <url> represents the JDBC driver–specific URL format.
• The syntax is dependent on the JDBC driver being used. For an in-memory H2 database with a database name of “test”, that’s thus jdbc:h2:mem:test.
• The H2-specific MODE=LEGACY path parameter is basically a work around for Hibernate incompatibility with SQL IDENTITY type, you could try removing this part in a newer Hibernate version.
• The H2-specific DB_CLOSE_DELAY=-1 path parameter basically instructs its JDBC driver not to automatically shut down the database when it hasn’t been accessed for some time, even though the application server is still running.
• After configuring the data source, a concrete instance of the javax.sql.DataSource can now be injected in any servlet container managed artifact such as a servlet or filter as follows:

@Resource
private DataSource dataSource;

• You could get an SQL connection from it via DataSource#getConnection() for the plain old JDBC work.

Configuring Jakarta Persistence

• To familiarize Jakarta Persistence with the newly added data source, Edit the persistence unit entry in the persistence.xml as follows:

<persistence-unit name="PersistenceUnitName" transaction-type="JTA"> 
    <jta-data-source>java:global/DataSourceName</jta-data-source> 
    <properties>
        <property name="jakarta.persistence.schema-generation.database.action" value="drop-and-create" />
    </properties> 
</persistence-unit>

• The value of drop-and-create which basically means that the web application should automatically drop and create all SQL tables based on Jakarta Persistence entities.
• For real-world applications, you’d better pick either create or none (which is the default). Or better yet, a real data base server such as PostgreSQL instead of an in-memory database.

Facelets File

• It’s basically just an XHTML file that is by Jakarta Faces interpreted as a Facelets file or just Facelet.
• When the FacesServlet is invoked with a URL matching the path of this Facelets file, then Jakarta Faces will parse it and generate the HTML markup that is sent to the browser as a response to the request. With help of EL, it can reference a bean property and invoke a bean action.
• Jakarta Faces–specific XHTML tags are also called Jakarta Faces Components.
• In the Eclipse Servers view, right-click the WildFly server entry and choose Add and Remove
• Add the WAR projects to the server. Do so for the newly created project and finish the wizard to deploy it to the server.
• Start the server and navigate to your http://localhost:8080/<artifactId>.<version>, which you can also find in the /standalone/deployments folder of the WildFly installation.
• Or in WildFly server log, it’ll be the line identified by WFLYUT0021, search for WFLYUT0021 to find the context path part .
• Adjust the file name and hence the context path part of the Maven-generated WAR file as follows in the pom.xml

<build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
        <plugin></plugin>
        ........
    </plugins>
</build>

• The context path part can also be set to simply /, the deployed web application will then end up in the domain root.
• To do that in WildFly, create the JBoss-specific jboss-web.xml as src/main/webapp/WEB-INF/jboss-web.xml then add

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE jboss-web PUBLIC
    "-//JBoss//DTD JBOSS 5.0//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd" 
>
<jboss-web> 
    <context-root>/</context-root>
</jboss-web>

• Right-click on the server and choose Clean, to redeploy the web app for the changes to reflect
• Use the Faces 4.0–introduced automatic extensionless mapping feature so we do not need to specify the .xhtml extension in the URL.
• This can be achieved by adding the following entry to the web.xml

<context-param> 
    <param-name>
        jakarta.faces.AUTOMATIC_EXTENSIONLESS_MAPPING 
    </param-name>
    <param-value>true</param-value> 
</context-param>

• Make a desired .xhtml the default landing file so you don't specify in the URL. Add the following to the web.xml

<welcome-file-list> 
    <welcome-file>hello.xhtml</welcome-file>
</welcome-file-list>

Backing Bean

• It’s basically just a simple Java class that is by Jakarta Faces convention called a Backing Bean since it backs a View.
• Add CDI @Named and @RequestScoped annotations on the class so that it becomes a CDI managed bean
• @Named: gives the bean a name, which is used to reference it via EL in the view. Without any attributes, this name defaults to the simple class name with the first letter in lowercase.
• @RequestScoped: gives the bean a scope, which means the same bean instance is used throughout the given life span. In this case, that life span is the duration of an HTTP request. When the scope ends, the bean is automatically destroyed.