Hi Advitiya, it would be nice if there is a configuration option not only for Deserializer but also Serializer for java.util.Date / java.util.Calendar.
The dev team made a great job in applying the w3c specification 100% ... unfortunately a lot of the 3th party application that try to use the REST / SOAP functions generated by Axis2 do not :-/ So you will need to workaround and find a solution for that ... I would prefer Axis would give users the freedom to customize the Serialization by configuration (not by patching the sources). Sebastian 2012/3/7 Advitiya Garg <a.ga...@gmail.com> > > Hi, > > Is there any one found the solution as given by Brad, I am facing the same > issue and wanted the system date as default. > > > Regards > Adi > > Brad Lohnes 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. :-) > > > > > > > > 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 > > > > > > > > > > > > -- > View this message in context: > http://old.nabble.com/Changing-Default-Time-Zone-in-CalendarDeserializer--tp4722785p33461536.html > Sent from the Axis - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org > > -- Sebastian Wagner http://www.openmeetings.de http://incubator.apache.org/openmeetings/ http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
