I've just upgraded from Spring 3.0.7 to Spring 3.1.2. I have a test that ensures that when I try to bind String data to a date field in a bean using a particular date format, and I provide a date in the wrong format, it should produce an error. This test started failing when I upgraded to Spring 3.1.2, because it seems to have introduced functionality where if the first converter fails, TypeConverterDelegate falls back to using a constructor that accepts an argument of the initial type for the destination type. This is probably a good feature in most cases, except in the case of java.util.Date, where that constructor has been deprecated since Java 1.1, is locale dependent, and probably should never ever be used in any circumstance.
Good point. We're not falling back to that String constructor algorithm if a corresponding ConversionService attempt failed before anymore. We're only doing so now if no other converter/editor has been registered, as a last resort (just like in 3.0.x).
James Roper opened SPR-9865 and commented
I've just upgraded from Spring 3.0.7 to Spring 3.1.2. I have a test that ensures that when I try to bind String data to a date field in a bean using a particular date format, and I provide a date in the wrong format, it should produce an error. This test started failing when I upgraded to Spring 3.1.2, because it seems to have introduced functionality where if the first converter fails, TypeConverterDelegate falls back to using a constructor that accepts an argument of the initial type for the destination type. This is probably a good feature in most cases, except in the case of java.util.Date, where that constructor has been deprecated since Java 1.1, is locale dependent, and probably should never ever be used in any circumstance.
Affects: 3.1.2
Referenced from: commits ff7dcec, 9862fbf
The text was updated successfully, but these errors were encountered: