axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sapozhnikov, Michael" <>
Subject To <choice> or not to <choice>?
Date Wed, 08 Oct 2003 20:20:09 GMT
In our XSDs we use <choice> elements, which give me a hard time with AXIS.
In the first case (similar to what is described in the bug,
opened a year ago) this XSD fragment:
  <complexType name="AritemForOneType"> 
      <extension base="tbl:ForOneType"> 
          <element name="Key0_CUSTOMER_HKEY" type="tns:CUSTOMER_HKEYFieldsType"/> 
          <element name="Key1_NUMBER_HKEY" type="tns:NUMBER_HKEYFieldsType"/> 
          <element name="Key2_SOFT_KEY" type="tns:SOFT_KEYFieldsType"/> 
          <element name="Key3_SOFT_KEY2" type="tns:SOFT_KEY2FieldsType"/> 
          <element name="Key4_NOTE_HKEY" type="tns:NOTE_HKEYFieldsType"/> 
          <element name="Key5_PO_NUMBER" type="tns:PO_NUMBERFieldsType"/> 
          <element name="Key6_ADJ_CONS_HKEY" type="tns:ADJ_CONS_HKEYFieldsType"/> 
will result in XML with all elements included in the message. To unset not needed elements
I use in my client code trick like this for all not needed elements:
            field = (ElementDesc)_for.getTypeDesc().getFieldByName("key0_CUSTOMER_HKEY");
This is not nice, but doable.  A possible workaround to modify the schema to set each element's
minOccurs to zero does not look as a good solution.
In the second case I have a real problem, when choice elements have the same name, but come
from different namespaces:
  <complexType name="CorqhiMultiRowRequest"> 
      <extension base="glb:AxsMultiRowRequest"> 
            <element ref="view01:queryClause"/> 
            <element ref="view02:queryClause"/> 
where view01 and view02 are namespace prefixes. The resulting Java proxy code generated is:
public class CorqhiMultiRowRequest  extends com.axsone.axis.comp.AxsMultiRowRequest  implements {
    private com.axsone.axis.cipoepic.CorqhiQuery queryClause;
    private com.axsone.axis.cipoepic.Corqhi1Query queryClause;
 end so on...
which declares two fields with the same name and certainly does not compile. It looks to me
that it's not too hard to fix it (e.g. by prefixing member field name with a namespace prefix
for the not unique field names)
I would really appreciate if all these could be fixed. All our XSDs are generated by custom
tool and I cannot change element names to avoid compile problems, because these "view" XSDs
don't have knowledge where and how they will be combined in a <choice> group in another
I am using AXIS 1.1.

View raw message