I'm building a web service in java, deploying it under Jboss-as-7.1.1.Final,
based on org.apache.cxf 2.4.6.
I need to expose a web method that takes in input a date field that can
reach many centuries in the past. At the moment I'm using java.util.Date in
my request bean. So, my web method is
/public UpdatePersonResponse updatePerson(UpdatePersonRequest request) {
...
}/
The request bean UpdatePersonRequest has the date field, with getter and
setter:
/...
private Date birthday;
.../
In the soap request that I'm testing I put:
<birthday>1452-04-15</birthday>/
The apache cxf logs show:
/16:07:36,568 INFO [org.apache.cxf.interceptor.LoggingInInterceptor] ...
Inbound Message
[...]
<birthday>1452-04-15</birthday>/
(this is correct)
A custom log I added into the set method of the request bean shows:
16:07:36,843 DEBUG com.xxx.xxx.service.request.UpdatePersonRequest ...
called setBirthday with argument [06/04/52 0.00]/
(this is wrong)
Then the request bean is valorized as follows:
/UpdatePersonRequest [... birthday=Thu Apr 06 00:00:00 CET 1452, ...]/
(this is wrong)
So I obtain 1452 April 06, and not 1452 April 15.
I tried with different dates, for example, soap:
/<birthday>1452-04-30</birthday>/
custom log:
/21:11:51,607 DEBUG [com.xxx.xxx.service.request.UpdatePersonRequest] ...
called setBirthday with argument [21/04/52 0.00]/
(wrong)
The bean is valorized with:
/UpdatePersonRequest [... birthday=Fri Apr 21 00:00:00 CET 1452 ...]/
(again wrong)
*I obtain April 21 and not April 30*, with *9 days of difference*.
I tried with several dates and noticed that this behavior occurs for dates
prior then *15/10/1582*, that is the historical start date for the Gregorian
Calendar.
From 15/10/1582 onward the request bean is valorized with the exact date I
enter in the soap request.
So, I don't understand what is the logic used by Apache Cxf. Does it assume
that the incoming request contains a date expressed in Gregorian calendar
and then convert it into Julian date for dates prior that 15/10/1582? If it
is so, why does such a conversion is performed?
Thank you very much.
based on org.apache.cxf 2.4.6.
I need to expose a web method that takes in input a date field that can
reach many centuries in the past. At the moment I'm using java.util.Date in
my request bean. So, my web method is
/public UpdatePersonResponse updatePerson(UpdatePersonRequest request) {
...
}/
The request bean UpdatePersonRequest has the date field, with getter and
setter:
/...
private Date birthday;
.../
In the soap request that I'm testing I put:
<birthday>1452-04-15</birthday>/
The apache cxf logs show:
/16:07:36,568 INFO [org.apache.cxf.interceptor.LoggingInInterceptor] ...
Inbound Message
[...]
<birthday>1452-04-15</birthday>/
(this is correct)
A custom log I added into the set method of the request bean shows:
16:07:36,843 DEBUG com.xxx.xxx.service.request.UpdatePersonRequest ...
called setBirthday with argument [06/04/52 0.00]/
(this is wrong)
Then the request bean is valorized as follows:
/UpdatePersonRequest [... birthday=Thu Apr 06 00:00:00 CET 1452, ...]/
(this is wrong)
So I obtain 1452 April 06, and not 1452 April 15.
I tried with different dates, for example, soap:
/<birthday>1452-04-30</birthday>/
custom log:
/21:11:51,607 DEBUG [com.xxx.xxx.service.request.UpdatePersonRequest] ...
called setBirthday with argument [21/04/52 0.00]/
(wrong)
The bean is valorized with:
/UpdatePersonRequest [... birthday=Fri Apr 21 00:00:00 CET 1452 ...]/
(again wrong)
*I obtain April 21 and not April 30*, with *9 days of difference*.
I tried with several dates and noticed that this behavior occurs for dates
prior then *15/10/1582*, that is the historical start date for the Gregorian
Calendar.
From 15/10/1582 onward the request bean is valorized with the exact date I
enter in the soap request.
So, I don't understand what is the logic used by Apache Cxf. Does it assume
that the incoming request contains a date expressed in Gregorian calendar
and then convert it into Julian date for dates prior that 15/10/1582? If it
is so, why does such a conversion is performed?
Thank you very much.