Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of vreddyp@gmail.com designates
 64.233.170.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Lw/wMNya6YhnIHNhI9emvdC/AaXBamujt8OTsvHAqG6NkJwZvKoobSAr15k3fJaGmUsmaT9TqBBfoj3oVe1AoNIXg/9VkRz+a9UUa59aGhSSiXSmWqTlJS9Y6wghh/gvRV+Y7OYrqNuxiiRhjL0yIKcW4QLLjp/3H9sS0mo4fhg=
Message-ID: <fadf6631050626060512f270b1@mail.gmail.com>
Date: Sun, 26 Jun 2005 18:35:09 +0530
From: Venkat Reddy <vreddyp@gmail.com>
Reply-To: Venkat Reddy <vreddyp@gmail.com>
To: "axis-dev@ws.apache.org" <axis-dev@ws.apache.org>
Subject: Re: [jira] Commented: (AXIS-1456) Mapping of service interfaces
 defined using java.sql.Date to xsd:date does not work
In-Reply-To: <19e0530f05062605532353126d@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <939010866.1089888999524.JavaMail.apache@nagoya>
	 <507214291.1119789057669.JavaMail.jira@ajax.apache.org>
	 <fadf66310506260549228ca8e7@mail.gmail.com>
	 <19e0530f05062605532353126d@mail.gmail.com>

I agree.

One last tiny question :-) we can possibly get java.util.Date from
xsd:dateTime instead of xsd:date, for default cases?

- venkat

On 6/26/05, Davanum Srinivas <davanum@gmail.com> wrote:
> Venkat,
>=20
> See from the point of view of someone using Axis. they would be
> confused if they get a java.util.sql.Date. can't hack the code just to
> get roundtrip working. I will look more.
>=20
> -- dims
>=20
> On 6/26/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> > Well, it does map to java.util.Calendar as required by JAX-RPC when
> > the typemapping flag is appropriately specified. But without the type
> > mapping switch, may be it can default to java.util.sql.Date.
> > Otherwise, is there a way we can make the roundtrip test case work
> > (which i submitted)?.
> >
> > - venkat
> >
> > On 6/26/05, Davanum Srinivas (JIRA) <axis-dev@ws.apache.org> wrote:
> > >     [ http://issues.apache.org/jira/browse/AXIS-1456?page=3Dcomments#=
action_12314505 ]
> > >
> > > Davanum Srinivas commented on AXIS-1456:
> > > ----------------------------------------
> > >
> > > that's against JAXRPC spec
> > >
> > > -- dims
> > >
> > > > Mapping of service interfaces defined using java.sql.Date to xsd:da=
te does not work
> > > > -------------------------------------------------------------------=
----------------
> > > >
> > > >          Key: AXIS-1456
> > > >          URL: http://issues.apache.org/jira/browse/AXIS-1456
> > > >      Project: Apache Axis
> > > >         Type: Bug
> > > >   Components: Serialization/Deserialization
> > > >     Versions: 1.1
> > > >  Environment: Multiple environments (i.e. UNIX and Windows based)
> > > >     Reporter: Alan Murphy
> > > >     Assignee: Venkat Reddy
> > > >  Attachments: DateDeserializer.java.patch, sqldate-testcase.zip
> > > >
> > > > Whilst JAX-RPC does not define a standard mapping from a Java class=
 to xsd:date, Apache Axis has a non standard extension which maps service i=
nterfaces defined using java.sql.Date to xsd:date. Unfortunately this does =
not work out-of-the-box. When a parameter of type xsd:date is sent from a c=
lient stub to an AXIS server, it is erroneously deserialized as a java.util=
.Date. This is despite the fact that both the WSDD, and XML request, specif=
y that the parameter is of type XSD:Date, rather than XSD:DateTime.
> > > > The resultant effect of this incorrect deserialization, is that AXI=
S will erroneously try to find a method to invoke with a java.util.Date in =
it's signature, rather than a java.sql.Date (which the method signature act=
ually specifies), and hence will throw a 'no such method error'.
> > > > The problem is resolved by implementing a custom deserializer which=
, when registered against the type java.sql.Date, merely converts the incor=
rectly deserialized java.util.Date to a java.sql.Date, allowing AXIS to inv=
oke the correct method.
> > > > The code for the overriden makeValue function of the custom deseria=
lizer is as follows:
> > > > public Object makeValue(String source) {
> > > >
> > > >    Object obj =3D super.makeValue(source);
> > > >
> > > >    if (javaType =3D=3D java.sql.Date.class) {
> > > >               if (obj instanceof java.sql.Date) {
> > > >               return obj;
> > > >               } else if (obj instanceof java.util.Date) {
> > > >                       return new                         java.sql.D=
ate(((java.util.Date)obj).getTime());
> > > >               }
> > > >    }
> > > >
> > > >         if (javaType =3D=3D java.util.Date.class) {
> > > >               if (obj instanceof java.util.Date) {
> > > >                       return obj;
> > > >               }
> > > >       }
> > > >
> > > >         throw new RuntimeException(
> > > >               "cannot convert " + obj.getClass().getName() + " to "=
 + javaType.getName()
> > > >               );
> > > >     }
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the administrator=
s:
> > >    http://issues.apache.org/jira/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see:
> > >    http://www.atlassian.com/software/jira
> > >
> > >
> >
>=20
>=20
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>