JiBX
  1. JiBX
  2. JIBX-348

codegen - generating <collection> in binding xml without usage=optional with minOccurs=0

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JiBX 1.2.1
    • Fix Version/s: JiBX 1.2.3
    • Component/s: CodeGen
    • Labels:
      None
    • Number of attachments :
      0

      Description

      codegen is generating binding xml with <collection> element having no usage=optional even when the minOccurs is set to zero (maxOccurs=unbounded)

      XSD Snippet:
      <xsd:complexType name="ABC">
      <xsd:sequence>
      <xsd:element type="test:xxT" name="xx"
      minOccurs="0" maxOccurs="unbounded" />
      </xsd:sequence>
      </xsd:complexType>

      binding Xml:

      <collection get-method="getXxs" set-method="setXxs">
      <structure map-as="ns2:xxT" name="xx"/>
      </collection>

      Thanks,
      Arnab

        Activity

        Hide
        Dennis Sosnoski added a comment -

        Although this may be counterintuitive, it's by design. <collection> binding components always represent the equivalent of minOccurs="0" maxOccurs="unbounded". The only reason you'd need usage="optional" on a <collection> element of the binding is if there were a wrapper element name associated with the collection, and that wrapper element were itself optional - corresponding to this type of schema structure:

        <xs:element name="wrapper">
        <xs:complexType>
        <xs:complexContent>
        <xs:sequence>
        <xs:element name="value" type="xs:string"/>
        </xs:sequence>
        </xs:complexContent>
        </xs:complexType>
        </xs:element>

        Show
        Dennis Sosnoski added a comment - Although this may be counterintuitive, it's by design. <collection> binding components always represent the equivalent of minOccurs="0" maxOccurs="unbounded". The only reason you'd need usage="optional" on a <collection> element of the binding is if there were a wrapper element name associated with the collection, and that wrapper element were itself optional - corresponding to this type of schema structure: <xs:element name="wrapper"> <xs:complexType> <xs:complexContent> <xs:sequence> <xs:element name="value" type="xs:string"/> </xs:sequence> </xs:complexContent> </xs:complexType> </xs:element>
        Dennis Sosnoski made changes -
        Field Original Value New Value
        Assignee Dennis Sosnoski [ dsosnoski ]
        Dennis Sosnoski made changes -
        Resolution Not A Bug [ 6 ]
        Status Open [ 1 ] Closed [ 6 ]
        Hide
        Arnabkanti added a comment - - edited

        Without usage="optional" in the binding.xml , jibx does not allow collection attribute to be NULL. It expects an empty list or array (otherwise throws nullpointer exception ).

        If this is by design, then there should be a provision in customization so that the binding.xml can be generated with usage="optional" for collections when there is no wrapper element.

        This is only happening while generating bindings from XSD ( and it is generating usage="optional" when binding is generated from Java Code)

        Show
        Arnabkanti added a comment - - edited Without usage="optional" in the binding.xml , jibx does not allow collection attribute to be NULL. It expects an empty list or array (otherwise throws nullpointer exception ). If this is by design, then there should be a provision in customization so that the binding.xml can be generated with usage="optional" for collections when there is no wrapper element. This is only happening while generating bindings from XSD ( and it is generating usage="optional" when binding is generated from Java Code)
        Arnabkanti made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        Resolution Not A Bug [ 6 ]
        Hide
        Dennis Sosnoski added a comment -

        The code generated from schema by JiBX CodeGen is designed to always have a collection present, so this issue will only arise if you're setting the collection to null in your own code. The current generated code API doesn't make it clear that the value should not be set to null, though, so I'll agree that something should be done differently.

        It should be possible to make the <collection> optional even with no wrapper element, and I'll look at making that change for the next release.

        Show
        Dennis Sosnoski added a comment - The code generated from schema by JiBX CodeGen is designed to always have a collection present, so this issue will only arise if you're setting the collection to null in your own code. The current generated code API doesn't make it clear that the value should not be set to null, though, so I'll agree that something should be done differently. It should be possible to make the <collection> optional even with no wrapper element, and I'll look at making that change for the next release.
        Dennis Sosnoski made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Fix Version/s JiBX 1.2.3 [ 16349 ]
        Resolution Fixed [ 1 ]
        Hide
        Klaus Claszen added a comment -

        Would be glad to see this change be revoked according to JIBX-449 and this email.

        Show
        Klaus Claszen added a comment - Would be glad to see this change be revoked according to JIBX-449 and this email .

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Arnabkanti
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: