You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Biesbrock, Kevin" <Bi...@aoins.com> on 2011/12/19 21:22:28 UTC
BigDecimal type conversion
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.convertValue()
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
RE: BigDecimal type conversion
Posted by "Biesbrock, Kevin" <Bi...@aoins.com>.
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" <Bi...@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
Re: BigDecimal type conversion
Posted by Dave Newton <da...@gmail.com>.
Either a type convertor, or an interceptor that trims everything.
d.
On Dec 19, 2011 3:23 PM, "Biesbrock, Kevin" <Bi...@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.convertValue()
>
> 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
>
>