I'd give an annotation in your xml schema a shot. This example is for JAXB which of course Axis doesn't support. Axis2 does support a wider range of databinding libs, including jaxbri - though I'm not sure how well it works at this point. You could be better off looking at xmlbeans or jibx . I'm showing this example for you to get an idea of how you might solve the problem:

<xs:annotation>
    <xs:appinfo>
      <jaxb:globalBindings>
        <jaxb:javaType name="java.util.Calendar" xmlType="xs:date" printMethod="gov.infoseg.mr.xtrans.jaxb_misc.DateConverter.printCalendar" parseMethod="gov.infoseg.mr.xtrans.jaxb_misc.DateConverter.parseCalendar"/>
      </jaxb:globalBindings>
    </xs:appinfo>
  </xs:annotation>

So my issue was that I was also getting GMT appended to my result. I fixed it by:

public class DateConverter
{
  static final SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");

  static public String printCalendar(Calendar c)
  {
    return df.format(c.getTime());
  }

  static public Calendar parseCalendar(String c) throws ParseException
  {
    Date d = df.parse(c);
    Calendar cal = Calendar.getInstance();
    cal.setTime(d);
    return cal;
  }
}

HTH,
Robert
http://www.braziloutsource.com/

On 6/5/06, Brad Lohnes <[EMAIL PROTECTED]> wrote:

Hello,

 

I am new to the list and apologize if this question has already been answered – I spent a few hours searching for the issue but did not find it.

 

Here is the issue:

 

When converting XML dateTime types, axis converts to java.util.Calendar, which is fine. However, the implementation of CalendarSerializer hard-codes the time zone to "GMT" (and also hard-codes the format, as well).

 

We have implemented a web service using axis but have received a new requirement very late in the project (scheduled to finish testing this week). The requirement is that our web service assume not GMT at the interface endpoint, but rather another timezone (GMT+12:00). This means two things:

 

  1. When we receive an XML dateTime element with no time zone information, we must assume our local time zone, not GMT.
  2. When serializing our own output, we are required to not include time zone information, and other services within the SOA are to assume local timezone information.

 

I am not interested in debating the merits of this design – our opinion has been made clear. Nevertheless, it is our requirement. J

 

How can we replace the existing axis functionality?

 

  1. Is there a simple configuration option? (I have not found one)
  2. Is there a simple way to replace (through configuration) the CalendarDeserializer implementation with our own?
  3. Is there another option that has not been considered?
  4. Is the only option to replace the CalendarDeserializer class and compile axis ourselves? (We are currently working from the distribution library rather than compiliing from source ourselves).

 

Your urgent response in this matter would be greatly appreciated.

 

Regards,

 

Brad

 


Reply via email to