I found two "strange" behaviours in the Source Generator when handling XML schema which defines nested choice/sequence anonymous elements, as in the following example:
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault=" qualified" attributeFormDefault="unqualified"> <xs:complexType name="FooType"> <xs:sequence> <xs:choice> <xs:sequence> <xs:element name="childA" type="xs:string"/> <xs:element name="childB" type="xs:string"/> </xs:sequence> <xs:element name="another" type="xs:string"/> </xs:choice> <xs:element name="anelement" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="rootel" type="FooType"/> </xs:schema> the first is the source generator tries to handle twice the element mapped as FooTypeChoiceSequence, so prompting to overwrite it. The second is in the FooTypeChoice generated element, which has a _mypackagename_FooTypeChoiceSequence field which name contains the full package name of the generated class (and so the setter/getter emthods for that field). I used some (maybe "dirty") workarounds to have the builder work properly on my schemas: For the first problem, I tried to look at the generator source, and I tried commenting a call to processContentModel(group, sInfo) in the createClasses(Group group, SGStateInfo sgInfo) of the SourceGenerator class. It seems calling this method has no effect in the generated source in many cases (or maybe some time-wasting), and cause the duplicate handling of the anonymous element in the case I mentioned above. After commenting this line I have no more the problem and it seems to work properly on the schemas I used for now. I dont know if this trick can cause the generator to work in a wrong manner in some other cases. For the second aspect (package name in field) I found that the JClass descriptor comes at a certain point with the fully qualified class name (set up as a cache elsewhere) so the corresponding field is generated with the full name (package + class) in the createFieldInfo (Group group, SGStateInfo sgState) method of class MemberFactory. I solve the problem simply trimming out the package from the class name before generating the field name, assuming it has no effect on the ambiguity of the field (and getter/setter methods) name itself. Can anyone tell me if these are really bugs or if I am wrong with something? regards, Michele ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
