----- Original Message ----- From: "Bill Pfeiffer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 15:22 Subject: Re: Simple little trick for easing (de)serialization issues
> Steve, > > I have bought into the interop thing because there's an extremely good > chance that my future clients (Insurance inducstry) will be using .NET and > Java. So I have one choice and that is to make interop work. Now reality > sets in. My data model contains java.sql.Date and ArrayList. I have no > problem with (the idea of) marshelling these to the least common denominator > of the SOAP types. Why not? SOAP supports arrays and datetimes. That's > what these things are when it comes down to it. > > My original question stands. How do I write the serializers for these for > the server side. Yes I will have to make assumptions, but I own the data > model and can do that (Soap array is an ArrayList, Soap Datetime is > java.sql.date). Is this possible? Has anyone done? Have examples? > There ought to be mappings for the sql.date, if not, ask for them or add them, its faster that way. Similarly, there is support for Vector, so you could use that to add ArrayLists. Use the source in org/apache/axis/encoding/ser as your starting point. sql.Date should map to xsd:datetime ; ArrayList becomes a sequence of elements in XML . I guess part of the problem there is typing. When you export/import a simple typed array, its obvious what you send and receive. Note I find xsd:datetime trouble. Java runtimes add the correct timezone info from a Calendar object, and expect the timezone to be valid on receipt. .NET doesnt, it assumes local TZ everywhere. This leads to more confusion, the further from GMT you are, but confusing it is when things are 8 hours apart on a local system. Nowadays I have given up on time and use a long instead, with that mapped to the classic time_t datatype
