I defined a special type instead. Have not tried globalBindings. Perhaps it is
just <jxb.javaType that you mistyped. Should be <jxb:javaType
This is what my definition looks like. As you see I use the standard parse
method since the date is perfectly valid even without the timezone info:
<xs:simpleType name="DateType">
<xs:annotation>
<xs:appinfo>
<jxb:javaType name="java.util.Calendar"
printMethod="se.abc.web.bbadmin.util.DateUtil.dateToString"
parseMethod="javax.xml.bind.DatatypeConverter.parseDate"/>
</xs:appinfo>
</xs:annotation>
Best regards
/Peter
Quoted from Sarah Hardy <Sarah.Hardy_at_tcplifesystems.com>:
> 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.
>
> ________________________________________________________________________
>
...................................................................
GRATIS LOKALNYHETER MED E-POST!
http://www.enytt.nu