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
