Details
- Type:
Bug
- Status:
Closed
- Priority:
Major
- Resolution: Fixed
- Affects Version/s: 1.0
-
- Component/s: XML code generator
- Labels:None
- Environment:Castor 1.0
Xerces 1.4.4
Java 1.4.2_11
Eclipse 3.0.2
- Number of attachments :
Description
The following part of the schema is not correctly translated. I assume the problem is that we have a value 'm' and 'M' in the list of restrictions:
XSD extract :
>
Generated code extract :
private static java.util.Hashtable init()
//-- java.util.Hashtable init()
Issue Links
- duplicates
CASTOR-193 case-sensitive bug with simpleType enumerations
CASTOR-1373 java classes generated overwriting due to similar names in XML
Activity
This should do to recreate the problem :
The Java code I used :
public class CreateSourceCode {
private final static String xsd = "data/test.xsd";
private final static String src = "company.test.model";
public static void main(String[] args) {
SourceGenerator srcGen = new SourceGenerator();
try{ srcGen.setDestDir("c:/temp/src"); srcGen.generateSource(xsd, src); System.out.println("done"); }
catch (FileNotFoundException e){ // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); }
}
}
The XSD file :
<xs:schema xmlns:
<xs:element
<xs:complexType>
<xs:attribute
<xs:attribute
>
</xs:complexType>
</xs:element>
</xs:schema>
Lovely ..
Initial patch, highlighting the (assumed) changes to SourceFactory and the required modifications to the binding XML Schema instance.
Updated patch, providing the ability to define <enumBinding>s within a binding file.
Sample XML Schema (plus small JUnit test case) including a binding file to showcase the use of the aforementioned <enumBinding> element.
FYI, I just made up my mind to break this issue into several separate sub-tasks (as this will ease the required efforts to test the individual steps).
This is a result of problems in the area of regeneration of the binding file classes as a result of these changes. I do apologize for this delay, but somehow I am running into problems that are not 'nice' ...
.
Turns out that the binding.xsd specified elementForm to be 'unqualified' .. ;-(. Well, picking this up again ....
Some follow-up comments at
CASTOR-1491 ....
Just to let you know that I just deployed a new Maven snapshot release of Castor 1.0.6 at
that includes the patch as committed as part of this Jira issue.
Good Evening Werner. I tried the snapshot castor-1.0.6-20061209.124158-4.jar but wasn't able to make things work. I used the original code and XSD from this ticket to test it in Eclipse 3.1.2 with Java 1.4.2_11. Maybe I'm doing things not correctly. Should I define anything special to make this work ?
I'll attach the result I get using this snapshot.
Thanks.
Result when using snapshot : castor-1.0.6-20061209.124158-4.jar
Frederik, are you aware that you'll need to supply an <enumBinding for your scenario to get this going? I know that documentation still needs to be added, but have a look at the newly added CTF test cases, available at
especially the binding file specified in this folder.
I was not aware of that. I'll give this a try later on. If you could copy/paste a quick example of such a file that works with the above test case - that would be great
.
Frederik, in the directory referenced above, you'll find everything needed, XML schema, binding file, sample XML document instance. What else would you need ?
Nothing, maybe a nice cold beer and a week of holiday. I'm just being lazy I know.
I'll test again later this week.
Actually, have a look at in particular.
Hmm, fancy coming to Vienna ? I am sure nice cold beer is to be found here easily ......
Verified on my side. Thanks for the work and the solution
.
I'd really appreciate if the attached XSD could be simplified as much as possible, so that it contains structures relevant to the problem only. Thanks in advance ....