Helen
I'd like to offer another suggestion. I agree with Kenneth that long
makes a good, lightweight, serializable substitute for java.sql.Date
when you are working with, say RMI.
The JAX-RPC spec maps java.util.Date and java.util.Calendar to
xsd:dateTime, and in the other direction maps the SOAP xsd:dateTime
class to java.util.Calendar. If you are wanting cross-platform
compatibility (ie clients in languages other than Java), it is probably
desirable to represent the datetimes with the xsd:dateTime type rather
than xsd:long. For this reason, I've switched from using Date in my
complex objects (which I would prefer) to using Calendar (which I guess
has the time zone support that util.Date doesn't). The way that code is
generated via the .wsdl file in the very latest version of the sdk
caused my "java.util.Date" based objects to break (what started off as
Dates were transformed into Calendars in helper classes).
So, in short, my recommendation is to use java.util.Calendar.
Regards
Matthew
> I don't know if java.sql.Date is supported. But if you're
> going to convert it to something, try a long. (use
> getTime()). Also, remember that java.sql.Date extends
> java.util.Date, so if that class is supported, you might end
> up with a java.util.Date on the other side. Not sure.
>
> K.C.
>
> > -----Original Message-----
> > From: Helen Hunter [mailto:hhunter73_at_HOTMAIL.COM]
> > Sent: Saturday, December 14, 2002 11:46 AM
> > Subject: java.sql.Date support
> >
> > Hi again,
> > Does jax-rpc support java.sql.Date? I need to pass a
> complex object in
> > my request that has a Date property. Is this possible? Or should I
> > convert to String?
> >
> > -hh