Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 56226 invoked from network); 1 Mar 2007 07:46:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Mar 2007 07:46:41 -0000 Received: (qmail 33610 invoked by uid 500); 1 Mar 2007 07:46:44 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 33584 invoked by uid 500); 1 Mar 2007 07:46:43 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 33573 invoked by uid 99); 1 Mar 2007 07:46:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Feb 2007 23:46:43 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of hturksoy@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Feb 2007 23:46:32 -0800 Received: by ug-out-1314.google.com with SMTP id 30so290944ugs for ; Wed, 28 Feb 2007 23:46:11 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=lxn+h7yw3eH+gGQDJSdc9DifdpnpvjOcznOYOp5JqD7l38SZSqeJ6hPb2wV9cQXAH20tWVm4Zyr7FqAvAAF4/EJowAgCGywc32yxiW1XDctj+IlxeaHqWj24aANaf12b5/U502lRG+PGtVFJieHp9Haj3q2JfTfMKzVXK84QqLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DUxzUxH1BxGFdnFl+Qf3zO1SU9Xz7/pNwV0mMudippycuClWfKdw00jsuVak5zzAwJgSPPcuwofOq8nmTyvArI0tZIc9MR8el8njy0ar2ZPX1cEeN5UTDBJuWjAPE7v+TaYbJb44vFOqFS44klodsU/3yu0eQ0WJUjIrELfMlwg= Received: by 10.78.149.13 with SMTP id w13mr130693hud.1172735170183; Wed, 28 Feb 2007 23:46:10 -0800 (PST) Received: by 10.78.175.19 with HTTP; Wed, 28 Feb 2007 23:46:10 -0800 (PST) Message-ID: <7f813dac0702282346p1ed29cbcp67ab431d7439187e@mail.gmail.com> Date: Thu, 1 Mar 2007 09:46:10 +0200 From: "Hasan Turksoy" To: "Jakarta Commons Users List" Subject: Re: [validator] intRange(between 0-100) validation fails for 1234 value because of a locale issue In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32277_10683486.1172735170155" References: <7f813dac0702281014g68df66dbq8ddcb33fc4141fbd@mail.gmail.com> <55afdc850702281348g631e5a02i8dd5d00989432df6@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_32277_10683486.1172735170155 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline in fact, shale's converter converts my 12345 number to "123.45" string... but this is the normal behaviour.. my locale's grouping character used while generating string value from integer value... this is same as jsf ri converter's behaviour... Issue raiser is C-V's GenericTypeValidator not concerning default locale while validating "123.45" string value... GenericTypeValidator has two formatInt method: 1- formatInt(String value) : no locale specified.. so it works as "return new Integer(value);" 2- formatInt(String value, Locale locale) : uses provided locale while formatting value. if locale is not provided, uses default locale to format the value... integer validator uses the 1. method.. as a result it throws a numberformatexception at line "return new Integer(value);" (value="123.45 ").. if 1.method use the 2. method with null locale parameter.. it would format my value according to the default locale and there would be no problem... my solutioun: 1. method should use 2.method with null locale parameter instead of "new Integer(value)" conversion.... hope i've cleared the issue.... regards, hasan.. On 3/1/07, Craig McClanahan wrote: > > On 2/28/07, Niall Pemberton wrote: > > This question relates to Shale's validation rather than commons > > validator - you're more likely to get an answer asking this on their > > user list. > > > > Actually, Niall, there are C-V related issues here. Even in the US > locale, the Commons Validator default formatting methods will convert > an integer 1234 into string "1,234", but the C-V validator routine > will not accept that as a valid integer string on a subsequent form > post -- it only wants "1234". I haven't had time to nail down the > precise boundaries of the problem, but there is definitely a C-V > related problem here. It should generate string values that are > accepted by a subsequent validation (especially in the case where the > user did not actually change the value). > > > Niall > > > > Craig > > > On 2/28/07, Hasan Turksoy wrote: > > > hi all, > > > > > > i am using an intRange validator together with an integer converter > for my > > > input field.. code is like below; > > > > > > > > > > > > > > > > > > this means; my field will be validated for the 5<->100 range with an > integer > > > value which will be converted by the shale's " > > > org.apache.shale.validator.converter.IntegerConverter" class... > > > > > > issue: > > > if i enter values less than 1000; validator(GenericValidator class) is > > > working as expected... But, if i enter values more than 1000, then, it > gives > > > a validation error saying my field's value(1234) must be integer! > > > This is because when i entered a value like 1234, converter converts > my > > > value to string (validator-rules need string value to make integer > > > validation) as "123.4".. so, it puts a thousand separator while > converting > > > my value to string... in this case, GenericTypeValidator's "formatInt" > > > method fails while creating a new Integer from this string... It's > trying to > > > do like; > > > "return new Integer("123.4");"... > > > > > > suggestion: > > > why this "formatInt(String value)" method of GenericTypeValidator is > NOT > > > using overridden "formatInt(String value, Locale locale);" method with > null > > > locale parameter?.. However, if it did like that; it will use the > default > > > locale while parsing my string to integer... and it will work as > expected... > > > > > > best regards, > > > > > > hasan... > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > ------=_Part_32277_10683486.1172735170155--