<< Back to previous view

[JAVAEETUTORIAL-249] Duke's Tutoring Administration Panel: editing student record has problems Created: 20/Sep/13  Updated: 25/Mar/14  Resolved: 25/Mar/14

Status: Closed
Project: javaeetutorial
Component/s: examples
Affects Version/s: 7.0.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: jendrock Assignee: Ian Evans
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive validationTest-0.1.zip     Zip Archive validationTest-ee6.zip    
Tags:
Participants: Ian Evans, jendrock, Kim Haase and rcervera

 Description   

In the Administration Panel of the Duke's Tutoring case study example, strange things happen when you try to edit a student. Let's give Buster Bluth a shot.

Click Edit in Buster Bluth's row.
Move "Buster" from Nickname to Middle Name and click Submit.
You'll see three error messages that indicate you need to fill out the Email, Cell Phone, and Home Phone fields because they are required, but aren't filled in in the existing student record.
Click Submit again.
Click Administration main page and notice that "Buster Bluth" is now known as "Bluth". He has no first name, even though I left the First Name field alone; I just modified the Nickname and Middle Name fields.



 Comments   
Comment by rcervera [ 20/Sep/13 10:21 PM ]

It works when filling all the fields in the page; the record gets updated. Probably the fields below (phone, etc) are not validating properly because they are empty.

Comment by Kim Haase [ 20/Sep/13 11:40 PM ]

I think what Eric found was that even after he filled in those fields and clicked Submit, the data was not recorded correctly.

Comment by jendrock [ 21/Sep/13 01:29 PM ]

Yes, what Kim says is correct. There are 2 issues, the first being that the existing data about the students does not conform to the validation checks for the Email, Cell Phone, or Home Phone fields. There should be some indication that these fields are required. That said, the existing data should conform to those requirements as well. It does not.

The issue that pushed my buttons was the randomness of what happens when Name (First, Middle, Last) and Nicknames are filled out. I can look at the Name data for an existing student in the list, create a new student and fill out the same fields as are shown for the existing student and get an end result that is quite different than what is expected. Try to create a new student in the manner that I previously described and compare the results to George Bluth.

This is just one of the Admin issues. I will write up and add the others sequentially. For example, we can create a new guardian for a student but how can we display the guardians for that, or any, student?

All good case studies, like this one, exercise many different technologies and components, which lead to many interactions and combinations of interactions that need to be discovered, tested, and examined. It takes several different people looking at the same app to truly shake out the things that don't work. In the grand scheme of things, the things I found are relatively small and, while bothersome, do not render the app unusable by any stretch of the imagination. After the latest round of updates, I simply look at these blemishes as growing pains. I really like what the app shows under its skin. I know the user community does too.

Comment by Ian Evans [ 23/Sep/13 05:02 PM ]

The weird thing is that those fields are not required, despite the validation messages that show a violation.

@Email
protected String email;
@Pattern(regexp="\\(\\d{3}\\) \\d{3}-\\d{4}",
         message="{invalid.phonenumber}")
protected String homePhone;
@Pattern(regexp="\\(\\d{3}\\) \\d{3}-\\d{4}",
         message="{invalid.phonenumber}")
protected String mobilePhone;

Note that there is no @NotNull validation constraint on these fields. The empty fields in the Facelets form are apparently being set to something behind the scenes, causing the constraint violations. Which is bewildering.

Comment by Ian Evans [ 02/Oct/13 11:15 PM ]

JSF is interpreting the strings from the form as empty strings rather than null strings. This occurs even if you add the following to web.xml

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

Adding the above parameter appears to trigger different behavior, though, as you won't see the Bean Validation error message put on the constraint, but rather "A Persistence Error Occurred". This is caused by a ContraintViolationException thrown downstream by Bean Validation during the transaction.

Comment by Ian Evans [ 02/Oct/13 11:21 PM ]

The ZIP file contains a test case that shows the errors. A simple JPA entity with a non-required field has a @Pattern constraint. Any attempt to leave the input box blank in the JSF form results in a ConstraintViolationException.

Comment by Kim Haase [ 07/Oct/13 06:19 PM ]

The zip file validationTest-ee6.zip modifies the previous example to run on a Java EE 6 platform (glassfish3). The reported problem does not occur on EE 6, suggesting that it was introduced in EL 3.0.

Comment by Kim Haase [ 22/Oct/13 07:14 PM ]

In the actual Duke's Tutoring example (not the stripped-down version):

If I don't provide the INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter and I try to create a student with no email address or phone numbers, then when I click Submit I get an error message on the email field saying

must match "[a-z0-9!#$%&'*+/=?^_`{|}~-](?:\.[a-z0-9!#$%&'*/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?"

and error messages on both phone fields saying

Phone numbers should be of the form (xxx) xxx-xxxx.

In Person.java, none of these fields has the @NotNull annotation, only the @Pattern annotation.

If I do provide the INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter and I try to create a student with no email address or phone numbers, I immediately go to an Error 500 page that reports a ConstraintViolationException:

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: javax.ejb.EJBException
root cause

javax.faces.el.EvaluationException: javax.ejb.EJBException
root cause

javax.ejb.EJBException
root cause

javax.validation.ConstraintViolationException: Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'prePersist'. Please refer to embedded ConstraintViolations for details.
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.0 logs.

Comment by Kim Haase [ 23/Oct/13 01:34 PM ]

Here's another interesting wrinkle (this is the version with the latest fixes):

I did not have the context parameter javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL set.

I created a student with a first name, last name, and nickname, clicked Submit, and got red validation errors because I left out the email and phone numbers. (This is an issue because those fields are not required; they just have pattern specifiers.)

Then I entered correct data in those fields and REMOVED THE FIRST NAME and then clicked Submit again. I did not get an error on the missing first name, though that is a required field. Instead, the student was created with the nickname as the first name.

The interaction between validation and persistence seems to be problematic here.

Comment by jendrock [ 25/Mar/14 08:40 PM ]

Since this isn't intended to be a real, fully operational application, these fixes will be left as an exercise for the reader to complete. Enjoy the example for what it is.

Generated at Mon Apr 21 14:59:25 UTC 2014 using JIRA 4.0.2#472.