Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.1
-
Fix Version/s: None
-
Component/s: XML code generator
-
Labels:None
-
Environment:Java 1.5, Windows XP, Eclipse IDE, Junit 3.8.1 execution, Ant gen task
-
Testcase included:yes
-
Number of attachments :4
Description
Find attached, sample simplified eclipse project.
Schema (castor-test-domain/xml/playlist/Playlist.xsd) includes a complex type object itemType with xs:dateTime fields: availabilityStart and availabilityEnd
<xs:complexType name="itemType">
<xs:complexContent>
<xs:extension base="baseDomain">
<xs:sequence>
<xs:element ref="description"/>
<xs:element ref="availabilityStart"/>
<xs:element ref="availabilityEnd"/>
</xs:sequence>
<xs:attribute name="id" type="xs:int"/>
<xs:attribute name="title" type="xs:string"/>
<xs:attribute name="active" type="xs:boolean"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Data appears in the format of : 01/26/2007 12:00:00 AM, which unhandled causes an exception running the junit test - testStringUnmarshal in TestPlaylist.java (under the test folder).
Source Gen binding on "/complexType:itemType" with member fields doesn't activate the handlers, but defining individual bindings for the members in the path does. (see attached binding file co-located with the schema)
Once bound, the call through the Unmarshaller method fails for a bad datetime format. Tracing the calls (and logging statements in the convertuponset method)) show no invocation.
com.foo.domain.exception.TransactionException: Bad DateTime format: 01/26/2007 12:00:00 AM
The Year must be 4 digits long
at com.foo.domain.playlist.XMLConverter.unmarshal(XMLConverter.java:176)
at com.foo.domain.playlist.XMLConverter.unmarshal(XMLConverter.java:124)
at com.foo.domain.test.playlist.TestPlaylist.testStringUnmarshal(TestPlaylist.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: Bad DateTime format: 01/26/2007 12:00:00 AM
The Year must be 4 digits long
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:740)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:596)
at com.foo.domain.playlist.XMLConverter.unmarshal(XMLConverter.java:168)
... 20 more
Caused by: java.lang.IllegalStateException: Bad DateTime format: 01/26/2007 12:00:00 AM
The Year must be 4 digits long
at org.exolab.castor.xml.handlers.DateFieldHandler.setValue(DateFieldHandler.java:173)
at org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:852)
at org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1108)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:726)
... 22 more
-
Hide
- bug1878.zip
- 23/Feb/07 4:53 PM
- 6 kB
- Drew Beechum
-
- bug1878/build.xml 1 kB
- bug1878/castorbuilder.properties 3 kB
- bug1878/entity.xml 0.5 kB
- bug1878/ItemTypeDateHandler.java 3 kB
- bug1878/log4j.properties 0.4 kB
- bug1878/mapping.xml 0.4 kB
- bug1878/Playlist.xsd 2 kB
- bug1878/playlistbinding.xml 1 kB
- bug1878/README.txt 0.1 kB
-
Hide
- CastorFieldHandlerBug.zip
- 16/Oct/08 11:59 AM
- 7 kB
- azgard
-
- CastorFieldHandlerBug/.classpath 4 kB
- CastorFieldHandlerBug/.project 0.3 kB
- CastorFieldHandlerBug/pom.xml 2 kB
- CastorFieldHandlerBug/.../DateTimeFieldHandler.java 1 kB
- CastorFieldHandlerBug/.../CustomDateTimeFieldTest.java 0.7 kB
- CastorFieldHandlerBug/src/.../binding.xml 0.4 kB
- CastorFieldHandlerBug/.../castorbuilder.properties 4 kB
- CastorFieldHandlerBug/.../fieldhandler.xml 0.1 kB
- CastorFieldHandlerBug/.../fieldhandler.xsd 0.3 kB
-
Hide
- castor-test-domain.zip
- 22/Feb/07 7:18 PM
- 4.22 MB
- Drew Beechum
-
- castor-test-domain/.classpath 0.8 kB
- castor-test-domain/.project 0.4 kB
- castor-test-domain/.../castorbuilder.properties 3 kB
- castor-test-domain/bin/.../.castor.cdr 0.4 kB
- castor-test-domain/bin/.../BaseDomain.class 1 kB
- castor-test-domain/.../BaseDomainDescriptor.class 1 kB
- castor-test-domain/.../ItemsDescriptor$1.class 2 kB
- castor-test-domain/.../ItemsDescriptor$2.class 2 kB
- castor-test-domain/.../ItemsDescriptor$3.class 2 kB
- castor-test-domain/.../ItemsDescriptor$4.class 2 kB
- castor-test-domain/.../ItemsDescriptor.class 3 kB
- castor-test-domain/.../ItemTypeDescriptor$1.class 2 kB
- castor-test-domain/.../ItemTypeDescriptor$2.class 1 kB
- castor-test-domain/.../ItemTypeDescriptor$3.class 2 kB
- castor-test-domain/.../ItemTypeDescriptor$4.class 1 kB
- castor-test-domain/.../ItemTypeDescriptor$5.class 1 kB
- castor-test-domain/.../ItemTypeDescriptor$6.class 1 kB
- castor-test-domain/.../ItemTypeDescriptor.class 5 kB
- castor-test-domain/.../PlaylistDescriptor$1.class 1 kB
- castor-test-domain/.../PlaylistDescriptor.class 3 kB
- castor-test-domain/.../VideoTypeDescriptor$1.class 1 kB
- castor-test-domain/.../VideoTypeDescriptor.class 3 kB
- castor-test-domain/.../TransactionException.class 0.7 kB
- castor-test-domain/.../AvailabilityEndHandler.class 2 kB
- castor-test-domain/.../AvailabilityStartHandler.class 2 kB
- castor-test-domain/.../ItemTypeDateHandler.class 2 kB
- castor-test-domain/bin/.../Items.class 9 kB
- castor-test-domain/bin/.../ItemType.class 4 kB
- castor-test-domain/.../XMLConverter.class 7 kB
- castor-test-domain/bin/.../Playlist.class 2 kB
-
- patch.c1878.20070226.txt
- 26/Feb/07 4:33 AM
- 13 kB
- Werner Guttmann
Activity
Sorry to bother this, but I'd really appreciate if you tried to follow the guidelines available at
http://castor.org/how-to-submit-an-xml-bug.html
Thanks in advance
Werner
Changing your binding file to ...
<?xml version="1.0"?>
<binding xmlns="http://www.castor.org/SourceGenerator/Binding" defaultBindingType='type'>
<package>
<name>xml.bug1878.generated</name>
<namespace>http://www.foo.com/foo</namespace>
</package>
<elementBinding name="/complexType:itemType/availabilityStart">
<member handler="xml.bug1878.ItemTypeDateHandler" />
</elementBinding>
<elementBinding name="/complexType:itemType/availabilityEnd">
<member handler="xml.bug1878.ItemTypeDateHandler" />
</elementBinding>
<complexTypeBinding name="baseDomain">
<java-class name="BaseDomain" package="xml.bug1878" abstract="true" />
</complexTypeBinding>
</binding>
does cause your custom handler to be bound against the members 'availabilityStart' and 'availabilityEnd'.
JUnit test case relative to src/bugs (with corrected binding file).
Sorry. It binds just fine, but I still get the date conversion errors:
Caused by: java.lang.IllegalStateException: Bad DateTime format: 01/26/2007 12:00:00 AM
The Year must be 4 digits long
at org.exolab.castor.xml.handlers.DateFieldHandler.setValue(DateFieldHandler.java:173)
I also see that whenever an empty node (e.g. <availabilityStart/>) on marshalling Castor calls in with a new Date object timestamped to now.
It looks like you are being hit a by a bug related to extending GeneralizedFieldHandler when writing your own FieldHandler (as actually mentioned in the HTML docs). Can you please try follow the instructions at
http://castor.org/xml-fieldhandlers.html#Writing-a-simple-FieldHandler
and report back whetehr this works for you ?
Using a simple field handler called AvailabilityStartHandler I get the same response.
#startElement: availabilityStart
2007-03-01 11:33:55,935 DEBUG [com.foo.domain.handler.AvailabilityStartHandler] - <asked to return newInstance from AvailStart>
#characters: 01/26/2007 12:00:00 AM
#endElement: availabilityStart
2007-03-01 11:33:55,935 ERROR [com.foo.domain.playlist.XMLConverter] - <XMLConverter - Unmarshal>
Bad DateTime format: 01/26/2007 12:00:00 AM
The Year must be 4 digits long
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:740)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:596)
I'm running into the same issue.
I try to add a simple custom fieldhandler for a element.with type dateTime and I get a "Bad Date Time Format"-Exception.
I think the problem is that castordoes not use in this case the custom fieldhandler, it use the fieldhandler from XMLClassDescriptor instead.
Test case added.
Hope this helps.
To work around this, we downloaded the Castor source and made a change.
In org.exolab.castor.xml.handlers.DateFieldHandler, changed line 475 from:
public boolean _allowNoTime = false;
to
public boolean _allowNoTime = true;
The code is well documented, so if you have questions you can look there. Essentially this enables the Date parsing to accept "date" fields instead of enforcing "datetime". It doesn't break parsing of "datetime". Look at DateFieldHandler.parse, line 362:
// If no time is present and we don't require time, use org.exolab.castor.types.Date if (pOptions._allowNoTime && trimmed.indexOf('T') == -1) { org.exolab.castor.types.Date parsedDate = new org.exolab.castor.types.Date(trimmed); return parsedDate.toDate(); } DateTime parsedDateTime = new DateTime(trimmed); return parsedDateTime.toDate();
Gary, just for the sake of completeness, does your custom handler extend from GeneralizedFieldHandler, or do you implement FieldHandler directly, ?
I tried both GeneralizedFieldHandler and FieldHandler directly. I had GeneralizedFieldHandflers working for other types (Strings, for instance), but for dates I had the same experience as above: setValue( ) not getting called
Co-worker pointed me to the castor.properties file today. Maybe a good candidate to slip a property in there regarding date/datetime. If you guys have an idea as to where/how this should be patched, contact me via email and I may be able to help.
Hi
I am also facing the same problem in caster
while doing marshelling it works fine, but while doing unmarshelling .. it showing error. i just tried the same whats given in example.can u please help me out
org.exolab.castor.xml.MarshalException: Bad DateTime format: 03/06/2009
Thanks
Prabu.p
I kept beating my head against this problem until I looked at the example for writing a GeneralizedFieldHandler one more time, and realized the big difference was I was setting the field type to java.util.Date and not string. As soon as I changed the field type to string, it worked exactly as I wanted it to.
I have the same problem with Castor 1.3.1 and sample GeneralizedFieldHandler code from http://castor.org/xml-fieldhandlers.html#Writing-a-simple-FieldHandler.
Stevi, I'm not sure how your change solved the problem.
Additional information:
Binding file segment looks like:
<complexTypeBinding name="/complexType:itemType/availabilityStart">
<member handler="com.foo.domain.handler.ItemTypeDateHandler"/>
</complexTypeBinding>
Binding as specified elsewhere:
<complexTypeBinding name="/complexType:itemType">
<member name="availabilityStart" handler="com.foo.domain.handler.AvailabilityStartHandler"/>
</complexTypeBinding>
Does not cause the generator to bind the handler to the specified member field.
-------------------------------------------
Handler source code can be found under src/com/foo/domain/handler. Both are modified examples from the project website.