Article formData = (Article)newCommandObject(Article.class);
提示：Errors binding onto object 'command'; nested exception is org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors Field error in object 'command' on field 'createTime': rejected value [2012-07-24]; codes [typeMismatch.command.createTime,typeMismatch.createTime,typeMismatch.java.sql.Timestamp,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [command.createTime,createTime]; arguments ; default message [createTime]]; default message [Failed to convert property value of type [java.lang.String] to required type [java.sql.Timestamp] for property 'createTime'; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [java.lang.String] to required type [java.sql.Timestamp] for property 'createTime': no matching editors or conversion strategy found]
最好是这样的，比起我们，spring的工程师，应该更见多实广吧，改一下类型，也不影响什么。ORM 会对日期类型很好的转换的。 :lol:
='201207-24'/> 手误，还是？ 2012-07-24？
java.sql.TimeStamp is derived from java.util.Date. It shouldn't be hard to figure out how to handle that in the persistence layer- in fact I'm willing to bet that some persistence tools can handle that conversion automatically.
In regard to your command object, however, you have a tougher problem using TimeStamp. I'll explain why.
As I noted, TimeStamp is derived from java.util.Date. Spring has an out-of-the-box CustomDateEditor property editor that does conversions from Strings (like on a form filled out by a user) to java.util.Date. It also converts from java.util.Date back to String when a BindingResult is being used to re-populate form fields because the submission failed validation.
Now, for the CustomDateEditor to take the Date it has converted your String to and "jam" it into a TimeStamp field is not possible because it requires an explicit downcast. Spring does no such thing on your behalf. In fact- off the top of my head, I don't think such a downcast is even legal in Java- meaning you'd get an exception.
Do you see why I'm recommending going back to java.util.Date? It's the standard class used for transporting date (and time) information.
If you're really gung-ho about sticking with java.sql.TimeStamp, however, your next best bet is to create your own CustomTimeStampEditor. Basically crack open and copy the code for Spring's CustomeDateEditor and then modify it to suit TimeStamp.