Kyle Stiemann from the Liferay Faces Team was kind enough to point out a flaw in the Java Server Faces libraries prior to versions JSF 2.3 and Mojarra 2.2.16 related to what I am presenting here. The solution requires two changes. The first is an addition to the web.xml file that you will see commented about in the file. The second change requires using newer versions JSF. Payara 4/Glassfish 4 manifests the problem. Payara 5/Glassfish 5, with the newer library, does not exhibit the problem. You can read about the problem at: JSFSPEC-1433 issue
Welcome to part 2 of 2 articles on confirming password entry into a JSF form. You should read part 1 at https://www.omnijava.com/2018/04/24/password-confirmation-on-a-jsf-page-part-1-a-simple-model/ to understand how I got to this point. In this example rather than a plain bean we will use the JPA with an Entity bean and a JPA controller as generated by my IDE of choice, NetBeans 8.2. In addition to using the JPA to save the login name and password, there is a new validator to ensure that the login name does not already exist in the database.
To run this code you will need MySQL or other SQL database. The scripts for creating the database and table are in src/test/resources. These must be run before you can execute the code.
You can download the project at https://gitlab.com/omniprof/JSFPasswordConfirmationEntityBean.git
To begin with let’s look at the NetBeans 8.2 generated Entity class:
This entity class is not under the management of CDI. Therefore the backing bean will be responsible for creating the entity bean in the getUser() method. The JPA controller class will be managed by CDI and is injected into the backing bean.
You should take note of the fact that JSR-303 Bean Validation annotations are used. Specifically, each field has an @Size annotation that comes from JSR-303. The same validation is also present on the JSF form using f:validateLength. Here is where I stumbled across an unusual behavior.
When I leave the fields blank I trigger the JSF required validation and the appropriate message from the bundle is displayed. When I exceed the length of the fields, 45 for login name and 12 for password something unusual occurs. I get two messages, one from the JSF validator and one from JSR-303. This does not make sense to me because I expect the JSR-303 validation to occur only if the JSF validation is successful and we apply the UI elements to the model. Searching for why this is occurring has not turned up a reason. If you know why this is happening please let me know.
There are two ways to handle this problem. The first is to remove all validation from the JSF form that matches a JSR-303 validation and only have JSR-303 validation in the bean. While this works it moves the validation away from the user interface. I prefer to validate closer to the user. The opposite approach, remove the JSR-303 validation from the bean, should never be done. Entity beans are filled not just from the user interface but from the database and possibly other classes in the application. There must be bean validation.
The solution I discovered is simple. You can prevent bean validation from occurring by adding:
<f:validateBean disabled="true" />
You only need to add this to the login name and password. The password confirm field is not in the entity so it is not subject to JSR-303 validation. Here is the JSF page.
I have added one additional validator. The login name is the primary key. Therefore, it is necessary to test if the login name is already in the database.
In the backing bean I have added the method validateUniquePassword. Here is the updated backing bean.
As mentioned earlier in this article the getUser() method creates the User entity, it is not injected. The validateUniquePassword method calls upon the JPA controller’s findUser method that either returns an entity or a null reference.
Everything is in place now. The form now validates that there is input in the fields, validates the length of the fields, validates that entry of the password in the two password fields is the same and validates that the login name will be unique in the database.