javaeetutorial
  1. javaeetutorial
  2. JAVAEETUTORIAL-249

Duke's Tutoring Administration Panel: editing student record has problems

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 7.0.3
    • Fix Version/s: None
    • Component/s: examples
    • Labels:
      None

      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.

        Activity

        Hide
        rcervera added a comment -

        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.

        Show
        rcervera added a comment - 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.
        Hide
        Kim Haase added a comment -

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

        Show
        Kim Haase added a comment - I think what Eric found was that even after he filled in those fields and clicked Submit, the data was not recorded correctly.
        Hide
        jendrock added a comment -

        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.

        Show
        jendrock added a comment - 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.
        Hide
        Ian Evans added a comment - - edited

        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.

        Show
        Ian Evans added a comment - - edited 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.
        Hide
        Ian Evans added a comment -

        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.

        Show
        Ian Evans added a comment - 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.
        Hide
        Ian Evans added a comment -

        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.

        Show
        Ian Evans added a comment - 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 .
        Hide
        Kim Haase added a comment -

        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.

        Show
        Kim Haase added a comment - 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.
        Hide
        Kim Haase added a comment -

        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.

        Show
        Kim Haase added a comment - 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.
        Hide
        Kim Haase added a comment -

        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.

        Show
        Kim Haase added a comment - 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.
        Hide
        jendrock added a comment -

        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.

        Show
        jendrock added a comment - 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.

          People

          • Assignee:
            Ian Evans
            Reporter:
            jendrock
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: