Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.1
-
Fix Version/s: 1.2
-
Component/s: XML code generator
-
Labels:None
-
Testcase included:yes
-
Number of attachments :4
Description
In the previous version of castor i was using (0.9.5) if you had an element with a type that did not exist in the schema then the source generation would fail but with 1.1 it simply makes the type a java.lang.Object and procedes happily.
using the following schema (note that there is no declaration of type 'blahblahblah'):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="HOST">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="ID">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="PASSWORD">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:complexType name="FLOWER">
<xs:sequence>
<xs:element name="HOST" type="HOST"/>
<xs:element name="ID" type="blahblahblah" />
<xs:element name="PASSWORD" type="PASSWORD"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
with castor 0.9.x you get the following error:
[javac] FLOWER.java:47: cannot find symbol
[javac] symbol : class ID
[javac] location: package mypackage.common
[javac] private mypacakge.common.ID _ID;
[javac] ^
but with castor 1.1 it happily builds the source setting the property 'ID' to a java.lang.Object in the source file.
attached is the bug template where i've only touched files in srcgen-bug.zip\bugs\xml\srcgen\template\ (i replaced the schema, and added some settings to the SourceGenerator object.
-
Hide
- srcgen-bug.zip
- 22/Mar/07 9:44 AM
- 32 kB
- Simon Lord
-
- bugs/AllTests.java 0.4 kB
- bugs/castor.properties 1 kB
- bugs/jdo/bug1900/BeanObject.java 0.6 kB
- bugs/jdo/bug1900/create.dll 0.1 kB
- bugs/jdo/bug1900/jdo-conf.xml 0.5 kB
- bugs/jdo/bug1900/mapping.xml 0.5 kB
- bugs/jdo/bug1900/TestFieldWithSpace.java 1.0 kB
- bugs/jdo/bug881/jdo-conf-a.xml 0.6 kB
- bugs/jdo/bug881/jdo-conf-ab.xml 1.0 kB
- bugs/jdo/bug881/jdo-conf-b.xml 0.6 kB
- bugs/jdo/bug881/JdoConfTest.java 7 kB
- bugs/jdo/bug881/mapping.xml 0.4 kB
- bugs/jdo/bug881/Product.java 0.3 kB
- bugs/jdo/c1355/app/City.java 0.9 kB
- bugs/jdo/c1355/app/Country.java 1 kB
- bugs/jdo/c1355/app/GolfCourse.java 0.8 kB
- bugs/jdo/c1355/app/GolfCourseHole.java 0.8 kB
- bugs/jdo/c1355/app/GolfCourseTees.java 2 kB
- bugs/jdo/c1355/app/MyAppObject.java 2 kB
- bugs/jdo/c1355/app/StateProv.java 0.6 kB
- bugs/jdo/c1355/jdo-conf.xml 0.5 kB
- bugs/jdo/.../LazyLoadRelationshipTest.java 3 kB
- bugs/jdo/c1355/mapping.xml 11 kB
- bugs/jdo/c1355/mysql.sql 8 kB
- bugs/.../TEST-LazyLoadRelationshipTest.txt 3 kB
- bugs/jdo/c1379/Computer.java 0.6 kB
- bugs/jdo/c1379/create.sql 0.4 kB
- bugs/jdo/c1379/jdo-conf.xml 0.8 kB
- bugs/jdo/c1379/mapping.xml 1 kB
- bugs/jdo/c1379/Product.java 0.8 kB
-
- patch.c1917.20070323.txt
- 23/Mar/07 8:32 AM
- 3 kB
- Werner Guttmann
-
- patch.c1917.20070330.txt
- 30/Mar/07 4:33 AM
- 5 kB
- Werner Guttmann
-
- patch.c1917.20080110.txt
- 10/Jan/08 8:01 AM
- 6 kB
- Werner Guttmann
Activity
I think that it should be easy to provide a patch that restores old (pre-1.0) behaviour, but somehow I think that an exception should be thrown instead to indicate that there's a type reference that cannot be resolved.
I agree - and it would make debugging easier if an exception was thrown that indicated that there's a type reference that cannot be resolved.
Initial patch for reviw, working around the 'java.lang.Object' problem, returning to uncompilable code for such unresolvable type references.
Before I can commit this patch, there's a few issues related to two or three broken CTF tests that need to sorted. In addition, I need a way to make a generation-only test as failing.
Simon, can I ask you to create a follow-up issue for the change with regards to exception handling. I'd like to make this patch available to restore things to pre-1.0 mode for the upcoming 1.2 release.
It looks like this is related to an oldish (BugZilla) bug with the number of 1471, where the following code is executed within MemberFactory.createFieldInfo() is the xsType is null.
if (xsType == null) {
{ case Structure.ATTRIBUTE: case Structure.ELEMENT: xsType = new XSClass(SGTypes.OBJECT); break; default: // probably a model-group break; }//-- patch for bug 1471 (No XMLType specified)
//-- treat unspecified type as anyType
switch (component.getAnnotated().getStructureType())
}
Which makes me wonder why we get that far at all ..
.