struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Biesbrock, Kevin" <Biesbrock.Ke...@aoins.com>
Subject RE: BigDecimal type conversion
Date Mon, 19 Dec 2011 21:12:31 GMT
Excellent!

Thank you,
Beez

P.S. No response on the "bug" comment. Out of curiosity, what is the reason for overriding
such trimming as seen by the parent class? Any idea?

-----Original Message-----
From: Dave Newton [mailto:davelnewton@gmail.com] 
Sent: Monday, December 19, 2011 3:25 PM
To: Struts Users Mailing List
Subject: Re: BigDecimal type conversion

Either a type convertor, or an interceptor that trims everything.

d.
 On Dec 19, 2011 3:23 PM, "Biesbrock, Kevin" <Biesbrock.Kevin@aoins.com>
wrote:

> Our application is rolling with Struts 2.2.1.
>
> One action class implements ModelDriven<E> and in the model we have a 
> Map<BusinessObjectA, BusinessObjectB>; where we rolled a custom type 
> converter for BusinessObjectA and BusinessObjectB has a BigDecimal. 
> This model has been in production for well over 4 months with no 
> issue; that is, until someone recently added a space to the end of the 
> related input field, e.g., "54 " (quotes added for emphasis).
>
> This causes 
> com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter to fail here:
>
> 402 if (toType == BigDecimal.class) {
> 403     return new BigDecimal((String) value);
>
> ...seemingly because it doesn't trim prior to creating a new BigDecimal.
>
>
> 1.       I feel like 403 should be calling bigDecValue(value, true) like
> the parent in
> com.opensymphony.xwork2.conversion.impl.DefaultTypeConverter.convertVa
> lue()
>
> 139 if (toType == BigDecimal.class)
> 140     result = bigDecValue(value);
>
> If #1 sounds like a candidate for a bug report, I would be happy to 
> report it if provided the appropriate url to post to.
>
>
> 2.       Our temporary solution will be to roll our own BigDecimal type
> converter so we can .trim() the string passed into the 
> constructor(String)
>
> Does #2 sound like the best solution? Do you have a more efficient or 
> less "custom" approach?
>
> Thank you for your time,
> Kevin Biesbrock
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message