I am currently having problems doing exactly the same thing, getting rid of
the time information from the end of dates.
I know that my binding file is being picked up because I have other
customisations that are working, but the global binding for xs:date seems to
be ignored. I haven't been able to find any examples of using javaType in
globalBindings.
My binding looks like this:
<jxb:globalBindings>
<jxb.javaType
name="java.util.Calendar"
xmlType="xs:date"
parseMethod="demo.util.DemoDatatypeConverter.parseDateToCal"
printMethod="demo.util.DemoDatatypeConverter.printCalToDate"/>
</jxb:globalBindings>
I am assuming that if it works the serialize methods in the impl classes wil
use my methods rather than the ones in javax.xml.bind.
I'd appreciate any help.
Regards,
Sarah Hardy
-----Original Message-----
From: Peter Lindvall [mailto:peter.lindvall_at_sverige.nu]
Sent: 16 April 2003 18:07
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Customaziation and validation
If you are not dependent on having the custom date format in the xml, an
option is to use xs:date in the xml and your custom format internally by
providing your own parse/print methods. That way you can still get the
benefits of xs:date's stronger validation support.
I solved a similar problem by providing a custom print method when I needed
to
get rid of the time zone information (2003-04-15+01:00).
Citerat fr?n Sriram Thyagarajan <Sriram_Thyagarajan_at_KEANE-NNE.com>:
> One thing I am not clear is, if Schema's default validation is always
> going
> to kick in, then won't this limit the customization described in Page 97
> of
> users guide particularly for xs:date types ?
>
> Overriding default bindings - "Override the specified default binding of
> XML
> Schema built-in datatypes to Java datatypes....."
>
> -----Original Message-----
> From: Sriram Thyagarajan
> Sent: Thursday, April 10, 2003 4:19 PM
> To: 'JAXB-INTEREST_at_java.sun.com'
> Subject: RE: Customaziation and validation
>
>
> Ok.. I got it... even though I define a method for parsing the value,
> it
> should still confirm to the date format of CCYY-MM-DD. I mis-understood
> it
> as a way of overriding the default validation i.e if I have a method
> customizing the conversion of xs:date to jxb:java.util.Calendar, I
> understood it as the method that would get executed whenever a xs:date
> field
> is encountered during unmarshalling and the default validation will not
> be
> executed ....
>
> So if a element is defined as xs:date it will always need to be in the
> format CCYY-MM-DD ? Is there a way to change this format ?
>
> Looks like the following happens... when a element defined as date and
> has
> the value 20030410
>
> 1. An even gets thrown, because it does not fall in the default format
> of
> CCYY-MM-DD
> 2. My customized method gets executed, which converts it into a
> java.util.Caledar object.
>
> My process aborts when there are ValidationEvents.. So even though the
> customized convertor, converted the value... because of the
> ValidationEvent,
> the process aborts...
>
> -----Original Message-----
> From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
> Sent: Thursday, April 10, 2003 3:42 PM
> To: JAXB-INTEREST_at_JAVA.SUN.COM
> Subject: Re: Customaziation and validation
>
>
> > Woudn't it be valid according to the Schema specs ? The schema
> defines
> an
> > element as type SimpleType and as the one which has different
> conversion
> > rules ?
>
> The conversion rules are defined by JAXB. So it's not something the XML
> Schema spec recognizes. And YYYYMMDD is NOT a valid xs:date value.
>
> It's this simple; your schema says the AccidentDate element will have
> the xs:date type. YYYYMMDD is not a valid xs:date value. Therefore
> <AccidentDate>20030410</AccidentDate> is not valid wrt your schema.
>
> Just try any XML schema processor out there. They should agree with
> this.
>
>
> > So does this mean that if I have validation turned on, then
> Conversion
> using
> > other methods cannot be done ?
>
> You can. It's just that the meaning of the validation is not affected
> by
> any of the JAXB customization. XML Schema validation is defined purely
> on the schema and the instance.
>
>
>
> > Just curious, one solution I can think in my situation is to catch
> that
> > event and discard it as if it did not happen...
>
> Would you elaborate what you think a problem is? Because I don't see
> any
> problem.
>
>
> regards,
> --
> Kohsuke KAWAGUCHI 408-276-7063 (x17063)
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
...................................................................
GRATIS LOKALNYHETER MED E-POST!
http://www.enytt.nu
________________________________________________________________________
This message is from TCPLifeSystems. The information
in this message is confidential and it is intended solely for the
addressee. Access to this message by anyone else is unauthorised. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it is prohibited
and may be unlawful. If you have received this message in error please
notify admin_at_tcplifesystems.com and delete it from your system.
Any views expressed by an individual within this message that do not
relate to the official business of the Computer Partnership Limited do
not necessarily reflect the views of the Computer Partnership Limited.
Unless otherwise stated any pricing information contained within this
message is subject to change.
TCP LifeSystems is a trading name of The Computer Partnership Ltd.
Whilst any attachments to this message may have been checked for
viruses, please rely on your own virus checker and procedures. We
therefore exclude all liability arising out of any viruses that might
exist in any attachment.
________________________________________________________________________