MyFaces Core
  1. MyFaces Core
  2. MYFACES-641

<f:convertNumber type="currency"/> not working properly.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: 1.1.0
    • Fix Version/s: None
    • Component/s: General
    • Labels:
      None
    • Environment:
      Win XP Professional SP2

      Description

      <h:outputText value=#

      {object.dollarAmount}

      ">
      <f:convertNumber type="currency"/>
      </h:outputText>

      When using the sun implementation of JSF it outputs the following: $1,200.55
      When using the MyFaces implemenation if output the following: ¤1,200.55

      The pattern being used is correct. But the currency symbol isn't automatically determined based on my locale the same way the SUN implementation is done.

      Having this automatically determined based on the systems locale makes this better for applications aiming to support multiple languages (I18N).

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          1971d 19h 22m 1 Leonardo Uribe 21/Feb/11 19:02
          Leonardo Uribe made changes -
          Assignee Leonardo Uribe [ lu4242 ]
          Leonardo Uribe made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Duplicate [ 3 ]
          Leonardo Uribe made changes -
          Link This issue duplicates MYFACES-2970 [ MYFACES-2970 ]
          sean schofield made changes -
          Workflow  MyFaces Workflow [ 12356651 ] MyFaces Workflow2 [ 12360460 ]
          sean schofield made changes -
          Workflow MyFaces Workflow2 [ 12355198 ]  MyFaces Workflow [ 12356651 ]
          sean schofield made changes -
          Workflow MyFaces Workflow [ 12353627 ] MyFaces Workflow2 [ 12355198 ]
          sean schofield made changes -
          Workflow MyFaces Workflow2 [ 12349056 ] MyFaces Workflow [ 12353627 ]
          sean schofield made changes -
          Workflow MyFaces Workflow [ 12347635 ] MyFaces Workflow2 [ 12349056 ]
          sean schofield made changes -
          Workflow MyFaces Workflow [ 12347635 ] MyFaces Workflow2 [ 12348979 ]
          sean schofield made changes -
          Workflow MyFaces Workflow [ 12347635 ] MyFaces Workflow2 [ 12348927 ]
          sean schofield made changes -
          Field Original Value New Value
          Workflow jira [ 12330571 ] MyFaces Workflow [ 12347635 ]
          Hide
          Lee Smith added a comment -

          Further comment, I've found a resolution to this problem and found its actually expected behaviour from reading the JSF specs.

          In JSF you configure it to specify which locales you support using the <locale-config> element on the <application> element in the faces-config.xml. JSF then uses this information and pulls out the correct locale from this list based upon the one supplied by the user (or more acurately their browser). If the locale the browser want's isn't available, JSF uses a default locale.

          If the <locale-config> element is not specified, the spec's don't define how JSF should determine the available locales. I guess this is where the difference between the RI and MyFaces must occurr - the RI must just pull the locale of the underlying JVM (which is probly en_US in your case), whereas MyFaces may return what it deems to be the default locale (probly just en).

          To fix this, i added the following to my faces-config.xml:

          <application>
          <locale-config>
          <default-locale>en_GB</default-locale>
          <supported-locale>en_US</supported-locale>
          <supported-locale>en_GB</supported-locale>
          </locale-config>
          </application>

          This should use USD if the browser is in US, GBP if the browser is in GB, and GBP otherwise. Doing the above ensures that even if the browser just supplied 'en' as the locale, I would still display a GBP symbol.

          As you want USD, you would want to change the <default-locale> element to en_US.

          Cheers, Lee

          Show
          Lee Smith added a comment - Further comment, I've found a resolution to this problem and found its actually expected behaviour from reading the JSF specs. In JSF you configure it to specify which locales you support using the <locale-config> element on the <application> element in the faces-config.xml. JSF then uses this information and pulls out the correct locale from this list based upon the one supplied by the user (or more acurately their browser). If the locale the browser want's isn't available, JSF uses a default locale. If the <locale-config> element is not specified, the spec's don't define how JSF should determine the available locales. I guess this is where the difference between the RI and MyFaces must occurr - the RI must just pull the locale of the underlying JVM (which is probly en_US in your case), whereas MyFaces may return what it deems to be the default locale (probly just en). To fix this, i added the following to my faces-config.xml: <application> <locale-config> <default-locale>en_GB</default-locale> <supported-locale>en_US</supported-locale> <supported-locale>en_GB</supported-locale> </locale-config> </application> This should use USD if the browser is in US, GBP if the browser is in GB, and GBP otherwise. Doing the above ensures that even if the browser just supplied 'en' as the locale, I would still display a GBP symbol. As you want USD, you would want to change the <default-locale> element to en_US. Cheers, Lee
          Hide
          Lee Smith added a comment -

          I've also experienced this problem and believe I have traced it to the locale. It seems that the converter is only receiving a locale with language information and no territory.

          In the Java libraries if only a language is specified the NumberFormat class doesn't replace the currency symbol (presumably becuase it doesn't know what to replace it with).

          This can be verified by manually creating a new NumberFormat instance using the following code:

          NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.EN);
          System.out.println(formatter.format(123.456));

          Which outputs:

          ¤123.46

          If however you use a locale which includes a territory:

          NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.UK);
          System.out.println(formatter.format(123.456));

          You get:

          £123.46

          Not sure why the coverter isn't getting a full locale - it might be becuase the browser isn't sending it through, or the browser is only sending a language and no territory. Although if you say this is working in the RI, this sounds unlikely.

          Cheers, Lee

          Show
          Lee Smith added a comment - I've also experienced this problem and believe I have traced it to the locale. It seems that the converter is only receiving a locale with language information and no territory. In the Java libraries if only a language is specified the NumberFormat class doesn't replace the currency symbol (presumably becuase it doesn't know what to replace it with). This can be verified by manually creating a new NumberFormat instance using the following code: NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.EN); System.out.println(formatter.format(123.456)); Which outputs: ¤123.46 If however you use a locale which includes a territory: NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.UK); System.out.println(formatter.format(123.456)); You get: £123.46 Not sure why the coverter isn't getting a full locale - it might be becuase the browser isn't sending it through, or the browser is only sending a language and no territory. Although if you say this is working in the RI, this sounds unlikely. Cheers, Lee
          Tim Mashinter created issue -

            People

            • Assignee:
              Leonardo Uribe
              Reporter:
              Tim Mashinter
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development