Re: axis2 Calendar convertToDateTime

2007-06-21 Thread zvika

Thanks for the replay , it was very helpful

but,
there is no way to configure the Adb to replace the converter to some other
custom one , or the favorite one ,to fix the problem and change that in the
ADB ,so the fix will be a permanent and will not require to change the
Convertor in every new version of axis that i will use.

thanks again ,
Zvika.



Jon Diprose wrote:
 
 Hi,
 
 Hit exactly the same problem recently. Detailed reading of the spec seems
 to 
 indicate that adb implements the minimum required by the spec, though
 perhaps 
 falls short in the requirement to properly document this.
 
 I spent a while rewriting convertToDateTime myself before I discovered
 that 
 (apologies for wrapping):
 
 
 import
 com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl;
 
 [snip]
 
 public static Calendar convertToDateTime(String source) {
  return XMLGregorianCalendarImpl.parse(source).toGregorianCalendar();
 }
 
 seemed to do a much more through job. Xerces and xml-apis.jar are in the 
 classpath, so why not? This implementation rounds fractional seconds to
 the 
 nearest millisecond, deals with BCE dates and year   and provides a
 pure 
 Gregorian calendar as per the spec. The only other major difference seems
 to 
 be that it throws IllegalArgumentExceptions where the original threw 
 NumberFormatExceptions. Might be nice to have the option of throwing an 
 exception if there is loss of precision but it does what I needed it to
 do.
 
 Unfortunately, the same class is too clever to reliably return an 
 xsd:dateTime-formatted string for convertToString(...) - it gives any of
 the 
 other xsd date/time formats depending on which fields are set in the
 calendar 
 - see javadocs. I ended up with:
 
 public static String convertToString(Calendar value) {
 
  // Set BCE flag if appropriate
  String era = ;
  if (GregorianCalendar.BC == value.get(Calendar.ERA)) {
  era = -;
  }
 
  // Build an appropriate SimpleDateFormat for the Zulu timezone
  // SimpleDateFormat seems to handle the variable length year itself
  // Spec indicates it should be pure Greogian
  SimpleDateFormat zulu = new SimpleDateFormat(era + 
 -MM-dd'T'HH:mm:ss.SSS'Z');
  GregorianCalendar c = new GregorianCalendar();
  c.setGregorianChange(new Date(Long.MIN_VALUE));
  c.setTimeZone(TimeZone.getTimeZone(GMT));
  zulu.setCalendar(c);
 
  // Sun JDK bug 
 http://developer.java.sun.com/developer/bugParade/bugs/4229798.html
  // Has been fixed since 1.4?
  return zulu.format(value.getTime());
 
 }
 
 Of course, you could just ensure that all the fields are set first and use 
 XMLGregorianCalendarImpl again.
 
 I've got updated test cases and a rebuilt axis2-adb-1.2.jar somewhere as
 well, 
 but its built for java5 so I think not strictly speaking correct.
 
 Sorry, don't have the source checked out or maven set up or anything. I'm 
 happy to send my source files to someone who does, if anyone wants them?
 
 Jon
 
 
 
 
 zvika wrote:
 hi!
 
 we started to make use of a webservice with generating an Apache Axis2
 ADB
 webservice client stub. 
 the webservice itself is provided by .NET on a IIS server.
 
 the problem we have is that when the webservice serialize a DateTime
 Object
 in a format of -MM-dd'T'HH:mm:ss.ss'Z'   ss - dynamic
 positions
 for the fractional seconds
 but the ADB (org.apache.axis2.databinding.utils.ConvertorUtil ) that used
 by
 Axis2 expect to format like -MM-dd'T'HH:mm:ss.sss'Z' when the
 fractional
 seconds no more then a three positions
 
 we understands from the webservice suppliers that the format is as define
 in
 W3 specification 
 http://www.w3.org/TR/xmlschema-2/#dateTime
 http://www.w3.org/TR/xmlschema-2/#dateTime 
 
 some samples that we get in invoking the  webservice 
 2007-06-20T17:00:37.8380863GMT+02:00
 2007-06-20T17:00:45.3GMT+02:00
 
 
 java.lang.RuntimeException: java.lang.NumberFormatException: Unparseable
 date: 2007-06-20T17:00:37.8380863GMT+02:00
  at
 com.orbograph.www.orboservice.OrboServiceStub.fromOM(OrboServiceStub.java:9400)
  at
 com.orbograph.www.orboservice.OrboServiceStub.GetServerTime(OrboServiceStub.java:777)
 
 
 
 
 Thanks,
 zvika.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/axis2-Calendar-convertToDateTime-tf3952614.html#a11229001
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: axis2 Calendar convertToDateTime

2007-06-21 Thread Jon Diprose
Ideally I'd get my changes committed to the source tree. I just haven't 
figured out how to make that happen yet!


I'm guessing creating a bug report and attaching fix...

Jon

zvika wrote:

Thanks for the replay , it was very helpful

but,
there is no way to configure the Adb to replace the converter to some other
custom one , or the favorite one ,to fix the problem and change that in the
ADB ,so the fix will be a permanent and will not require to change the
Convertor in every new version of axis that i will use.

thanks again ,
Zvika.



Jon Diprose wrote:

Hi,

Hit exactly the same problem recently. Detailed reading of the spec seems
to 
indicate that adb implements the minimum required by the spec, though
perhaps 
falls short in the requirement to properly document this.


I spent a while rewriting convertToDateTime myself before I discovered
that 
(apologies for wrapping):



import
com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl;

[snip]

public static Calendar convertToDateTime(String source) {
 return XMLGregorianCalendarImpl.parse(source).toGregorianCalendar();
}

seemed to do a much more through job. Xerces and xml-apis.jar are in the 
classpath, so why not? This implementation rounds fractional seconds to
the 
nearest millisecond, deals with BCE dates and year   and provides a
pure 
Gregorian calendar as per the spec. The only other major difference seems
to 
be that it throws IllegalArgumentExceptions where the original threw 
NumberFormatExceptions. Might be nice to have the option of throwing an 
exception if there is loss of precision but it does what I needed it to

do.

Unfortunately, the same class is too clever to reliably return an 
xsd:dateTime-formatted string for convertToString(...) - it gives any of
the 
other xsd date/time formats depending on which fields are set in the
calendar 
- see javadocs. I ended up with:


public static String convertToString(Calendar value) {

 // Set BCE flag if appropriate
 String era = ;
 if (GregorianCalendar.BC == value.get(Calendar.ERA)) {
 era = -;
 }

 // Build an appropriate SimpleDateFormat for the Zulu timezone
 // SimpleDateFormat seems to handle the variable length year itself
 // Spec indicates it should be pure Greogian
 SimpleDateFormat zulu = new SimpleDateFormat(era + 
-MM-dd'T'HH:mm:ss.SSS'Z');

 GregorianCalendar c = new GregorianCalendar();
 c.setGregorianChange(new Date(Long.MIN_VALUE));
 c.setTimeZone(TimeZone.getTimeZone(GMT));
 zulu.setCalendar(c);

 // Sun JDK bug 
http://developer.java.sun.com/developer/bugParade/bugs/4229798.html

 // Has been fixed since 1.4?
 return zulu.format(value.getTime());

}

Of course, you could just ensure that all the fields are set first and use 
XMLGregorianCalendarImpl again.


I've got updated test cases and a rebuilt axis2-adb-1.2.jar somewhere as
well, 
but its built for java5 so I think not strictly speaking correct.


Sorry, don't have the source checked out or maven set up or anything. I'm 
happy to send my source files to someone who does, if anyone wants them?


Jon




zvika wrote:

hi!

we started to make use of a webservice with generating an Apache Axis2
ADB
webservice client stub. 
the webservice itself is provided by .NET on a IIS server.


the problem we have is that when the webservice serialize a DateTime
Object
in a format of -MM-dd'T'HH:mm:ss.ss'Z'   ss - dynamic
positions
for the fractional seconds
but the ADB (org.apache.axis2.databinding.utils.ConvertorUtil ) that used
by
Axis2 expect to format like -MM-dd'T'HH:mm:ss.sss'Z' when the
fractional
seconds no more then a three positions

we understands from the webservice suppliers that the format is as define
in
W3 specification 
http://www.w3.org/TR/xmlschema-2/#dateTime
http://www.w3.org/TR/xmlschema-2/#dateTime 

some samples that we get in invoking the  webservice 
2007-06-20T17:00:37.8380863GMT+02:00

2007-06-20T17:00:45.3GMT+02:00


java.lang.RuntimeException: java.lang.NumberFormatException: Unparseable
date: 2007-06-20T17:00:37.8380863GMT+02:00
at
com.orbograph.www.orboservice.OrboServiceStub.fromOM(OrboServiceStub.java:9400)
at
com.orbograph.www.orboservice.OrboServiceStub.GetServerTime(OrboServiceStub.java:777)




Thanks,
zvika.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



axis2 Calendar convertToDateTime

2007-06-20 Thread zvika

hi!

we started to make use of a webservice with generating an Apache Axis2 ADB
webservice client stub. 
the webservice itself is provided by .NET on a IIS server.

the problem we have is that when the webservice serialize a DateTime Object
in a format of -MM-dd'T'HH:mm:ss.ss'Z'   ss - dynamic positions
for the fractional seconds
but the ADB (org.apache.axis2.databinding.utils.ConvertorUtil ) that used by
Axis2 expect to format like -MM-dd'T'HH:mm:ss.sss'Z' when the fractional
seconds no more then a three positions

we understands from the webservice suppliers that the format is as define in
W3 specification 
http://www.w3.org/TR/xmlschema-2/#dateTime
http://www.w3.org/TR/xmlschema-2/#dateTime 

some samples that we get in invoking the  webservice 
2007-06-20T17:00:37.8380863GMT+02:00
2007-06-20T17:00:45.3GMT+02:00


java.lang.RuntimeException: java.lang.NumberFormatException: Unparseable
date: 2007-06-20T17:00:37.8380863GMT+02:00
at
com.orbograph.www.orboservice.OrboServiceStub.fromOM(OrboServiceStub.java:9400)
at
com.orbograph.www.orboservice.OrboServiceStub.GetServerTime(OrboServiceStub.java:777)




Thanks,
zvika.
-- 
View this message in context: 
http://www.nabble.com/axis2-Calendar-convertToDateTime-tf3952614.html#a11214119
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: axis2 Calendar convertToDateTime

2007-06-20 Thread Jon Diprose

Hi,

Hit exactly the same problem recently. Detailed reading of the spec seems to 
indicate that adb implements the minimum required by the spec, though perhaps 
falls short in the requirement to properly document this.


I spent a while rewriting convertToDateTime myself before I discovered that 
(apologies for wrapping):



import 
com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl;

[snip]

public static Calendar convertToDateTime(String source) {
return XMLGregorianCalendarImpl.parse(source).toGregorianCalendar();
}

seemed to do a much more through job. Xerces and xml-apis.jar are in the 
classpath, so why not? This implementation rounds fractional seconds to the 
nearest millisecond, deals with BCE dates and year   and provides a pure 
Gregorian calendar as per the spec. The only other major difference seems to 
be that it throws IllegalArgumentExceptions where the original threw 
NumberFormatExceptions. Might be nice to have the option of throwing an 
exception if there is loss of precision but it does what I needed it to do.


Unfortunately, the same class is too clever to reliably return an 
xsd:dateTime-formatted string for convertToString(...) - it gives any of the 
other xsd date/time formats depending on which fields are set in the calendar 
- see javadocs. I ended up with:


public static String convertToString(Calendar value) {

// Set BCE flag if appropriate
String era = ;
if (GregorianCalendar.BC == value.get(Calendar.ERA)) {
era = -;
}

// Build an appropriate SimpleDateFormat for the Zulu timezone
// SimpleDateFormat seems to handle the variable length year itself
// Spec indicates it should be pure Greogian
SimpleDateFormat zulu = new SimpleDateFormat(era + 
-MM-dd'T'HH:mm:ss.SSS'Z');

GregorianCalendar c = new GregorianCalendar();
c.setGregorianChange(new Date(Long.MIN_VALUE));
c.setTimeZone(TimeZone.getTimeZone(GMT));
zulu.setCalendar(c);

// Sun JDK bug 
http://developer.java.sun.com/developer/bugParade/bugs/4229798.html

// Has been fixed since 1.4?
return zulu.format(value.getTime());

}

Of course, you could just ensure that all the fields are set first and use 
XMLGregorianCalendarImpl again.


I've got updated test cases and a rebuilt axis2-adb-1.2.jar somewhere as well, 
but its built for java5 so I think not strictly speaking correct.


Sorry, don't have the source checked out or maven set up or anything. I'm 
happy to send my source files to someone who does, if anyone wants them?


Jon




zvika wrote:

hi!

we started to make use of a webservice with generating an Apache Axis2 ADB
webservice client stub. 
the webservice itself is provided by .NET on a IIS server.


the problem we have is that when the webservice serialize a DateTime Object
in a format of -MM-dd'T'HH:mm:ss.ss'Z'   ss - dynamic positions
for the fractional seconds
but the ADB (org.apache.axis2.databinding.utils.ConvertorUtil ) that used by
Axis2 expect to format like -MM-dd'T'HH:mm:ss.sss'Z' when the fractional
seconds no more then a three positions

we understands from the webservice suppliers that the format is as define in
W3 specification 
http://www.w3.org/TR/xmlschema-2/#dateTime
http://www.w3.org/TR/xmlschema-2/#dateTime 

some samples that we get in invoking the  webservice 
2007-06-20T17:00:37.8380863GMT+02:00

2007-06-20T17:00:45.3GMT+02:00


java.lang.RuntimeException: java.lang.NumberFormatException: Unparseable
date: 2007-06-20T17:00:37.8380863GMT+02:00
at
com.orbograph.www.orboservice.OrboServiceStub.fromOM(OrboServiceStub.java:9400)
at
com.orbograph.www.orboservice.OrboServiceStub.GetServerTime(OrboServiceStub.java:777)




Thanks,
zvika.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]