Announcement Announcement Module
No announcement yet.
Apostrophe being stripped from spring:message Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Apostrophe being stripped from spring:message

    I have a web page form that displays any input validation error messages at the top of the page, as well as beside the field that has the error. At the top of the page we've used <spring:hasBindErrors> <spring:message> where the message is taken from Beside the field the error message is displayed using <form:errors>. Both link to the same message in the properties file

    The problem is that where we have an apostrophe in the text in the properties file it is being stripped from the <spring:message> so that the message "I'm not working" appears as "Im not working".

    It displays fine in the <form:errors> section.

    We have set defaultHtmlEscape to true in web.xml to cover off other form validation issues.

    We could manually set each <spring:message> and <form:errors> htmlEscape value to true and have the apostrophe appearing as ' in the properties file however there must be a simpler way.

    Has anyone seen this before?


  • #2
    found out a bit more about this issue. Our properties file had to be set so that any instance of an apostrophe was duplicated - for example, I'm had to be written as I''m. This is because <spring:messages> uses MessageFormat and according to the spec:

    Within a String, '' represents a single quote. A QuotedString can contain arbitrary characters except single quotes; the surrounding single quotes are removed. An UnquotedString can contain arbitrary characters except single quotes and left curly brackets. Thus, a string that should result in the formatted message "'{0}'" can be written as "'''{'0}''" or "'''{0}'''".

    As <form:errors> doesn't use MessageFormat any instance of double apostrophe's is written out as such, so you end up with things like I''m looking wrong.

    The only way we've found to solve this so far is to override the errors tag so that we can manually call MessageFormat.

    If anyone knows any other way of fixing this I would love to hear it.



    • #3
      Some extra info

      I realize this an older post now, but I just ran into something similar where my message contained:

      You can't destroy {1} of the {0} type as you only have {2}.
      I thought I'd mention it cause wembex wasn't testing a scenario where there are arguments... The output of the above message was appearing as:

      You cant destroy {1} of the {0} type as you only have {2}.
      So my {n} arguments weren't getting replaced... Initially I got rid of the apostrophe till I ran across this post...

      Now my message has the following:

      You can''t destroy {1} of the {0} type as you only have {2}.
      and displays correctly.

      Hope it helps others! Cheers


      • #4
        Actually, <form:errors> does use MessageFormat, but only if you pass in arguments. Note that the javadoc for the Errors.rejectValue() which takes the errorArgs parameter says this:

        errorArgs - error arguments, for argument binding via MessageFormat (can be null)

        It's no different with <spring:message>. An example:

        From the resource bundle:

        phrase1.msg=This is the {0}th user''s message.  It's very short.
        phrase2.msg=This is some user''s message. It's very short.
        From the html:

        HTML Code:
        <spring:message code="phrase1.msg"/><br/>
        <spring:message code="phrase1.msg" arguments="5"/><br/>
        <spring:message code="phrase2.msg"/><br/>
        <spring:message code="phrase2.msg" arguments="5"/><br/>
        This results in:

        This is the {0}th user''s message. It's very short.
        This is the 5th user's message. Its very short.
        This is some user''s message. It's very short.
        This is some user's message. Its very short.
        This seems inconsistent to me. In our application, we have some messages that get arguments passed into them, others which don't. So the resource bundle has to have a mix of double-quoted and single-quoted apostrophes. Something like this:

        error.user.general.firstname=User's first name is required.
        error.user.specific.firstname=User #{0}''s first name is required.