Uploaded image for project: 'Click'
  1. Click
  2. CLK-74

NPE in EmailField due to missing entry in click-control.properties

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Environment:
      Click 0.18, but I don't see it fixed in CVS

      Description

      When an invalid non-empty email is entered in the EmailField, the following NPE occurs:

      java.lang.NullPointerException
      at java.text.MessageFormat.applyPattern(MessageFormat.java:414)
      at java.text.MessageFormat.<init>(MessageFormat.java:350)
      at java.text.MessageFormat.format(MessageFormat.java:803)
      at net.sf.click.control.Field.getMessage(Field.java:516)
      at net.sf.click.control.Field.getMessage(Field.java:499)
      at net.sf.click.extras.control.EmailField.onProcess(EmailField.java:138)

      Looks like "email-format-error" key is missing from click-control.properties

        Activity

        Hide
        medgar Malcolm Edgar added a comment -

        Hi Andrus,

        This is a error strange for Click 0.18. The "email-format-error" is contained in the EmailField.properties file:

        http://cvs.sourceforge.net/viewcvs.py/click/click/extras/src/net/sf/click/extras/control/EmailField.properties?rev=1.1&view=markup

        I can't reproduce this error on the examples page:

        http://www.avoka.com/click-examples/big-form.htm

        Does you application include click-extras-0.18.jar ?

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - Hi Andrus, This is a error strange for Click 0.18. The "email-format-error" is contained in the EmailField.properties file: http://cvs.sourceforge.net/viewcvs.py/click/click/extras/src/net/sf/click/extras/control/EmailField.properties?rev=1.1&view=markup I can't reproduce this error on the examples page: http://www.avoka.com/click-examples/big-form.htm Does you application include click-extras-0.18.jar ? regards Malcolm Edgar
        Hide
        andrus Andrus Adamchik added a comment -

        Ok, now that you explained how it works, I was able to find the problem. It happens when using a subclass of a field (in my case an anonymous inner subclass). As a result the bundle key changes to something like "MyClass$1" and Click MessagesMap.ensureInitialized() can't find the bundle. E.g.:

        EmailField email = new EmailField("email", "E-Mail") {

        public boolean onProcess()

        { boolean returnValue = super.onProcess(); // set some properties of the owning form: setFromAddress(value); setReplyToAddress(value); return returnValue; }

        };

        I think that MessageMap should do a recursive bundle lookup through a superlcass hierarchy.

        Show
        andrus Andrus Adamchik added a comment - Ok, now that you explained how it works, I was able to find the problem. It happens when using a subclass of a field (in my case an anonymous inner subclass). As a result the bundle key changes to something like "MyClass$1" and Click MessagesMap.ensureInitialized() can't find the bundle. E.g.: EmailField email = new EmailField("email", "E-Mail") { public boolean onProcess() { boolean returnValue = super.onProcess(); // set some properties of the owning form: setFromAddress(value); setReplyToAddress(value); return returnValue; } }; I think that MessageMap should do a recursive bundle lookup through a superlcass hierarchy.
        Hide
        click_christian Christian Essl added a comment -

        Hi,

        I think this problem is common and it also relates to CLK-72.

        Like Andrus suggested IMO the MessageMap should do a recursive lookup through the superclass hierarchy and collect all messages in all the bundles in the hierarchy (This would than also solve CLK-72). Of course this should only be done once and the collected map should be cached.

        Christian

        Show
        click_christian Christian Essl added a comment - Hi, I think this problem is common and it also relates to CLK-72 . Like Andrus suggested IMO the MessageMap should do a recursive lookup through the superclass hierarchy and collect all messages in all the bundles in the hierarchy (This would than also solve CLK-72 ). Of course this should only be done once and the collected map should be cached. Christian
        Hide
        medgar Malcolm Edgar added a comment -

        Will be available in release 1.2

        Show
        medgar Malcolm Edgar added a comment - Will be available in release 1.2

          People

          • Assignee:
            medgar Malcolm Edgar
            Reporter:
            andrus Andrus Adamchik
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development