[#CASTOR-1917] Source generator does not fail on unresolved element types instead it sets them as java.lang.Object - jira.codehaus.org

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.

More Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

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
$i18n.getText("admin.common.words.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

Showing 30 of 57 items Download Zip
$i18n.getText("admin.common.words.show")

srcgen-bug.zip

22/Mar/07 9:44 AM

32 kB

Simon Lord

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Werner Guttmann added a comment - 23/Mar/07 4:13 AM

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) {
//-- patch for bug 1471 (No XMLType specified)
//-- treat unspecified type as anyType
switch (component.getAnnotated().getStructureType()) { case Structure.ATTRIBUTE: case Structure.ELEMENT: xsType = new XSClass(SGTypes.OBJECT); break; default: // probably a model-group break; }
}

Which makes me wonder why we get that far at all .. .

Show

Werner Guttmann added a comment - 23/Mar/07 4:13 AM 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) { //-- patch for bug 1471 (No XMLType specified) //-- treat unspecified type as anyType switch (component.getAnnotated().getStructureType()) { case Structure.ATTRIBUTE: case Structure.ELEMENT: xsType = new XSClass(SGTypes.OBJECT); break; default: // probably a model-group break; } } Which makes me wonder why we get that far at all ..

Hide

Permalink

Werner Guttmann added a comment - 23/Mar/07 5:27 AM

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.

Show

Werner Guttmann added a comment - 23/Mar/07 5:27 AM 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.

Hide

Permalink

Simon Lord added a comment - 23/Mar/07 6:39 AM

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.

Show

Simon Lord added a comment - 23/Mar/07 6:39 AM 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.

Hide

Permalink

Werner Guttmann added a comment - 23/Mar/07 8:32 AM

Initial patch for reviw, working around the 'java.lang.Object' problem, returning to uncompilable code for such unresolvable type references.

Show

Werner Guttmann added a comment - 23/Mar/07 8:32 AM Initial patch for reviw, working around the 'java.lang.Object' problem, returning to uncompilable code for such unresolvable type references.

Hide

Permalink

Werner Guttmann added a comment - 29/Mar/07 10:45 AM

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.

Show

Werner Guttmann added a comment - 29/Mar/07 10:45 AM 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.

Hide

Permalink

Werner Guttmann added a comment - 30/Mar/07 4:33 AM

Final patch for review.

Show

Werner Guttmann added a comment - 30/Mar/07 4:33 AM Final patch for review.

Hide

Permalink

Werner Guttmann added a comment - 10/Jan/08 7:57 AM

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.

Show

Werner Guttmann added a comment - 10/Jan/08 7:57 AM 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.

Hide

Permalink

Werner Guttmann added a comment - 10/Jan/08 8:01 AM

Updated patch, replacing all other patches attached.

Show

Werner Guttmann added a comment - 10/Jan/08 8:01 AM Updated patch, replacing all other patches attached.

People

Assignee:

Werner Guttmann

Reporter:

Simon Lord

Vote (0)

Watch (1)

Dates

Created:

22/Mar/07 9:44 AM

Updated:

14/Mar/08 6:40 AM

Resolved:

10/Jan/08 8:21 AM

Time Tracking

Estimated:

Not Specified

Remaining:

Logged:

30m