I built from cvs, unless there's another branch (I checked out from
the head) it wasn't fixed for my issue.
On 10/14/05, Ralf Joachim <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
> some other users have pointed us to this problem before that had been
> included in the 0.9.9 release of castor. As far as I know this is fixed
> in CVS and we intend to build a new bugfix release till end of this
> month. You may want to have a look at issues 1152, 1153 and 1216 which
> had recently been resolved.
>
> Having said that we would appreciate if you could test the CVS version
> to verify if your problem is also fixed.
>
> Regards
> Ralf
>
>
> Stephen Dennison schrieb:
> > This was a tough one to explain, so if the following isn't clear, feel
> > free to ask me to elucidate further.
> >
> >
> > I have a schema that has a simpleType that contains an attribute that
> > has a ref to an attribute group. In castor 0.9.5.2 this resulted in
> > code being generated for the attribute as though it were a simpletype,
> > but in castor 0.9.9 it just calls the field an Object and doesn't
> > generate code for it.
> >
> >
> > Here's an example of the setup:
> > I have one schema that contains something like this:
> > ...
> > <xsd:attributeGroup name="someStuff">
> > <xsd:attribute ref="classification" use="required"/>
> > <xsd:attribute ref="markings" use="optional"/>
> > </xsd:attributeGroup>
> > <xsd:attribute name="classification>
> > <xsd:simpleType>
> > <xsd:restriction base="xsd:string">
> > <xsd:enumeration value="one"/>
> > <xsd:enumeration value="two"/>
> > <xsd:enumeration value="three"/>
> > </xsd:restriction>
> > </xsd:simpleType>
> > </xsd:attribute>
> > <xsd:attribute name="markings">
> > ...
> > </xsd:attribute>
> > ...
> >
> > And I have another schema that has something like this:
> > ...
> > <xsd:complexType name="someComplexType">
> > <xsd:attributeGroup ref="theCorrectNS:someStuff"/>
> > </xsd:complexType>
> > ...
> >
> > So, in the 0.9.5.2, A class was generated for
> > someComplextTypeSomeStuffType that would allow the values one, two, or
> > three where one was defined as a static
> > someComplextTypeStuffType("one"), two was a static
> > someComplextTypeStuffType("two"), etc. (not sure of the actual
> > case/capitalization here, but you get the idea)
> > This class was referenced by the someComplextType class. like this:
> > ...
> > public class someComplexType implements java.io.Serializable{
> > ...
> > someComplexTypeSomeStuff _classficiation;
> > ...
> > }
> >
> > In castor 0.9.9, the same class looks like this:
> > ...
> > public class someComplexType implements java.io.Serializable{
> > ...
> > java.lang.Object _classification;
> > ...
> > }
> >
> >
> > For now, I can get a compatible class generated if I make simpleTypes
> > that restrict base type xsd:string, name them what I expect should
> > have been generated, put my enumerated values in them, and manually
> > add all of the attributes to someComplexType. The problem with this
> > is that I have to locate every place where we are using an attribute
> > group and manually build the simple types by inspecting all of the
> > schemas that we include.
> >
> >
> >
> > So, is this a bug, or is there a setting somewhere that I don't know
> > about that I need to turn on, or a syntax fix that I need, in order to
> > get backwards-compatible classes generated?
> >
> > -------------------------------------------------
> > If you wish to unsubscribe from this list, please
> > send an empty message to the following address:
> >
> > [EMAIL PROTECTED]
> > -------------------------------------------------
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
