Actually, can I please ask you to create a new Jira issue at http://www.codehaus.org/browse/CASTOR
and attach all relevant information as mentioned below. Regards Werner Werner Guttmann wrote: > Ric, > > thanks for pointing this out to us. It looks like the BNF spec didn't > get upgraded as it should have been before 1.1 .. :-(. > > As a matter of fact, bindings for complex and simple types as well as > groups now have to have a leading '/' in order to be picked up during > code generation. > > I will fix this in due time, and upload the HTML page in question to the > http://www.castor.org as soon as possible. > > Regards > Werner > > Ralf Joachim wrote: >> Hi Ric, >> >> another user has also reported problems with binding file at >> http://jira.codehaus.org/browse/CASTOR-1867. We'll try to investigate >> what happend and come back to you soon. >> >> Thanks for your analysis and report of the problem. >> >> Ralf >> >> >> Ric Klaren schrieb: >>> Hi, >>> >>> While upgrading to castor 1.1 I've run into a what looks to me strange >>> change in the binding file syntax. (Or I've been abusing the syntax so >>> far ;) ) >>> >>> A small example: >>> >>> ---- my castorbuilder.properties: >>> org.exolab.castor.builder.javaclassmapping=type >>> org.exolab.castor.builder.javaVersion=5.0 >>> ---- >>> >>> --- My XSD cut down to the basics: >>> <?xml version="1.0" encoding="UTF-8"?> >>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >>> attributeFormDefault="unqualified" elementFormDefault="qualified"> >>> >>> <xs:complexType name="TypeA"> >>> <xs:sequence> >>> <xs:element name="Yadda"> >>> <xs:complexType> >>> <xs:sequence> >>> <xs:element name="id" type="xs:string"/> >>> </xs:sequence> >>> </xs:complexType> >>> </xs:element> >>> </xs:sequence> >>> </xs:complexType> >>> >>> <xs:complexType name="TypeB"> >>> <xs:sequence> >>> <xs:element name="Yadda"> >>> <xs:complexType> >>> <xs:sequence> >>> <xs:element name="id" type="xs:string"/> >>> </xs:sequence> >>> </xs:complexType> >>> </xs:element> >>> </xs:sequence> >>> </xs:complexType> >>> >>> <xs:complexType name="Types"> >>> <xs:choice> >>> <xs:element name="TypeA" type="TypeA"/> >>> <xs:element name="TypeB" type="TypeB"/> >>> </xs:choice> >>> </xs:complexType> >>> >>> <xs:element name="Foo"> >>> <xs:complexType> >>> <xs:sequence> >>> <xs:element name="Bar" type="Types"/> >>> </xs:sequence> >>> </xs:complexType> >>> </xs:element> >>> </xs:schema> >>> >>> With castor 1.0.5 I used the following binding: >>> >>> <binding xmlns="http://www.castor.org/SourceGenerator/Binding" >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>> xsi:schemaLocation="http://www.castor.org/SourceGenerator/Binding >>> C:\\Castor\\xsd\\binding.xsd" >>> defaultBinding="type"> >>> >>> <complexTypeBinding name="TypeA"> >>> <java-class name="TypeA" package="my.org.type_a"/> >>> <elementBinding name="Yadda"> >>> <java-class name="Yadda" package="my.org.type_a"/> >>> </elementBinding> >>> </complexTypeBinding> >>> >>> <complexTypeBinding name="TypeB"> >>> <java-class name="TypeB" package="my.org.type_b"/> >>> <elementBinding name="Yadda"> >>> <java-class name="Yadda" package="my.org.type_b"/> >>> </elementBinding> >>> </complexTypeBinding> >>> </binding> >>> >>> Which did not work with Castor 1.1 anymore (e.g. conflicts between >>> generated classes appeared). I'm not sure wether I screwed something >>> up with the syntax from the start... So I looked at the docs and >>> thougth I would have to replace the name attribute with: >>> >>> ... >>> <complexTypeBinding name="complexType:TypeA"> >>> ... >>> >>> This did not help it turns out I had to change things to: >>> >>> <binding .... >>> <complexTypeBinding name="/complexType:TypeA"> >>> ... >>> </complexTypeBinding> >>> >>> <complexTypeBinding name="/complexType:TypeB"> >>> .... >>> </complexTypeBinding> >>> </binding> >>> >>> Looking at the BNF spec this seemed a bit odd to me. Anway I'm not >>> sure wether I've run into a problem or that I was using the wrong >>> syntax anyway. I hope someone can tell wether this is an oddity in >>> castor's codegenerator or that I've screwed up. >>> >>> As an aside note it would be nice if the codegenerator gave warnings >>> about unused constructs in the binding file. >>> >>> Cheers, >>> >>> Ric >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list please visit: >>> >>> http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

