BigDecimal and Locale in Grails

I was recently puzzled by strange behaviour of Grails application with web service interface. It resulted with rounding currency amount values when I sent request from my browser but it worked perfectly if another client application sent same…

I was recently puzzled by strange behaviour of Grails application with web service interface. It resulted with rounding currency amount values when I sent request from my browser but it worked perfectly if another client application sent same request. After investigation it turned out that the HTTP requests were not exactly identical. The browser request contained header entry with Polish locale pl-PL for which coma is a decimal separator.

Request
http://localhost:8080/helloworld/amount/displayAmount?amount=12.22

Header
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4

In order to reproduce this behaviour I created a simple Grails 2.1 HelloWorld app.

AccountController.groovy

package helloworld

class AmountController {

    def displayAmount(PaymentData paymentData) {
        render "Hello, this is your amount: " + paymentData.amount.toString()
    }
}

PaymentData.groovy:

    package helloworld

import grails.validation.Validateable

@Validateable
class PaymentData {
    BigDecimal amount

    static constraints = {
        amount(nullable: false, min: BigDecimal.ZERO, scale: 2)
    }
}

 

Starting this app we can observe rounding of cents in amount to 00 when sending request with dot in amount (http://localhost:8080/helloworld/amount/displayAmount?amount=12.22)


Whereas for amount with coma it gives a result with valid cent part (http://localhost:8080/helloworld/amount/displayAmount?amount=12,22)


Same behaviour might be expected in case of other locales that use coma as decimal separator, e.g. de_DE. Very not an obvious feature.

You May Also Like

Zabawy zespołowe: ćwiczenie głosu – RYBA!

Ćwiczenie ma za zadanie ośmielić osoby do mówienia głośno i wyraźnie. Ma też pomóc ustawić głos. Bardzo przydatne przy spotkaniach typu stand-up, gdzie "mruki" opowiadają pod nosem, co ostatnio robiły. Z mojego doświadczenia - działa!

Osoby biorące udział w ćwiczeniu stają w okręgu. Wybieramy sobie słówko do powtarzania. Proponowana jest ryba, ale może to być dowolne inne, proste w wymowie słowo.
Prowadzący ustala kierunek i jako pierwszy mówi szeptem ryba. Następnie, kolejne osoby powtarzają rybę, aż do donośnego"RYBA. Jeśli warunki pozwalają, można nawet krzyczeć, ale nie wrzeszczeć, bo wtedy wymowa jest niewyraźna. Po osiągnięciu maksymalnego (w pewnym sensie, ustalonego poziomu), zaczynamy ściszać głos, aż do szeptu. Naturalnie zabawę można powtórzyć dowolną ilość razy.

Jako szept warto przećwiczyć szept aktorski, czyli używanie szeptu, ale głośnego i wyraźnego, bez tembru głosu.

Mając jedno ustalone słowo, fajnie jest potem mobilizować kogoś kto mówi zbyt cicho wołając tylko "ryba!" i wtedy wszystko wiadomo.

Spring security authentication-success-handler-ref and authentication-failure-handler-ref does not work with KerberosServiceAuthenticationProvider

I'm using SpringSecurity with KerberosServiceAuthenticationProvider which is Kerberos security extension. You can read how to use it on extension author's blog.But you cannot use handler on form-login to catch authorization result. It's because of inne...I'm using SpringSecurity with KerberosServiceAuthenticationProvider which is Kerberos security extension. You can read how to use it on extension author's blog.But you cannot use handler on form-login to catch authorization result. It's because of inne...