Spring MVC has a very peculiar approach to handling dates from form submissions. Gone are what I feel is the ‘standard’ approach to forms, via select drop-downs, and in comes the open input text field. That may be valid especially if you are using a JavaScript-based date selector element. Fine.
The issue is that those JavaScript date selector elements select just that, dates, and if you need both date and time, you will normally resort to two fields, one for date and one for time. I followed this approach and hoped to rely on Spring’s CustomDateEditor
to handle the two fields separately, each with its own formatting. Issue is, that once you bind the CustomDateEditor
to a target class (in the initBinder
method of your controller), in this case java.util.Date
, that will be the only binding ANY field that needs to be a Date
object will use. You cannot have two custom property editors for the same target class.
One approach, as discussed in this message board discussion, recommends extending the CustomDateEditor
and using a subclass of java.util.Date
, such as java.sql.Time
, to allow for the separate binding. I am still OK with this somewhat cludgy approach. What happens to me is something far more bizarre. The errors I get when Spring attempts to perform the binding complain about the nature of the date string the custom binder is receiving:
Failed to convert property value of type [java.lang.String[]] to required type [java.sql.Date] for property 'date'; nested exception is java.lang.IllegalArgumentException: Could not parse date: Unparseable date: "[Ljava.lang.String;@1e07d3e,06/11/2008"
The interesting part here is the date: what Spring is getting is the something looking like an array of Strings, including the memory representation of a String object, sort of like a C-language pointer address. (WTF?)
I first examined the request object: when this was the initial submission of the form, the actual property for the field was invisible! In other words, calling request.getParameter(“date”) returned an empty String!
Looking further into this, I looked into I created a subclass of CustomDateEditor
which overrides its setValue()
method, so I can see what Spring MVC is passing into the property editor. Using Eclipse’s debugger, I discovered that what is passed in is indeed an array of Strings. The array contained two values – an empty string and the string containing the date that needed to parsed. Resubmitting the form put what I described as String pointer address value as the first member of the array, followed by the date string to be parsed.
I am truly puzzled by what is going on here. I am too tired to continue as it is late. Calling in the cavalry.