Quel est le but de minOccurs, nillable et restriction?

Documentation pour requis dit:

Si required() est
truepuis Javabean propriété est associé à un élément de schéma XML
déclaration avec minOccurs="1". maxOccurs est "1" pour une seule valeur
propriété et "unbounded" pour une propriété à valeurs multiples.

Si required() est falsepuis le Javabean propriété est mappée à XML
Schéma de la déclaration de l'élément avec minOccurs="0". maxOccurs est "1" pour un
une seule valeur de la propriété et "unbounded" pour une propriété à valeurs multiples.

Documentation pour nillable dit:

Si nillable() est truepuis le JavaBean propriété est mappée à un XML
Schéma nillable la déclaration de l'élément.

Code pour xs:complexType:

public class WSData {
    //...

    @XmlElement(required = true, nillable = false)
    public void setMonth(XmlMonthType month) {
        this.month = month;
    }

    public void setUserLogin(String userLogin) {
        this.userLogin = userLogin;
    }
}

Code pour xs:simpleType:

@XmlType
@XmlEnum(Integer.class)
public enum XmlMonthType {
    @XmlEnumValue("1")
    JANUARY,
    @XmlEnumValue("2")
    FEBRUARY,
    @XmlEnumValue("3")
    MARCH,
    /* ... months 4 ~9 ... */
    @XmlEnumValue("10")
    OCTOBER,
    @XmlEnumValue("11")
    NOVEMBER,
    @XmlEnumValue("12")
    DECEMBER;
}

Généré Schéma XML:

<xs:complexType name="wsData">
  <xs:sequence>
    <xs:element name="month" type="xs:string"/>
    <xs:element minOccurs="0" name="userLogin" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:simpleType name="xmlMonthType">
  <xs:restriction base="xs:int">
    <xs:enumeration value="1"/>
    <xs:enumeration value="2"/>
    <xs:enumeration value="3"/>
    <!-- ... months 4 ~9 ... -->
    <xs:enumeration value="10"/>
    <xs:enumeration value="11"/>
    <xs:enumeration value="12"/>
  </xs:restriction>
</xs:simpleType>

Les faits:

  1. La valeur par défaut pour minOccurs est 1. Donc, mois est nécessaire (doit exister);
  2. Le mois a un restriction. Donc, mois ne peut avoir qu'une valeur définie par l'une des 12 définis énumérations;
  3. La valeur par défaut pour nillable est faux. Donc, mois ne pouvez pas avoir des valeurs vides;
  4. Le Schéma XML est généré correctement.

Les problèmes:

  1. C'est l'acceptation du mois abcense (ne doit pas exister);
  2. C'est accepter toutes les valeurs par mois, de 13 (sauf quand il n'est pas parseable pour Integer);
  3. C'est l'acceptation des valeurs vides;

Je ne m'attendais pas à ces problèmes, suis-je raté quelque chose?
Si ce comportement est correct, quel est le but de requis, nillable et xs:restriction?

source d'informationauteur falsarella

  1. 9

    Nillable permet à des valeurs vides. Par exemple, si vous avez un Entier ou d'une Date, si elle accepte la valeur null, la balise XML pourrait être vide. Si ce n'est pas nillable, mais pas nécessaire, l'élément XML doivent exister avec un contenu valide ou n'existe pas du tout; une balise vide ne serait pas valide.

  2. 5

    Faire minOccurs 1, de faire des mois requis;

    La valeur par défaut pour minOccurs est l'un, de sorte que le month élément est nécessaire. Notez comment minOccurs="0" devait être ajouté à userLogin de le rendre facultatif.

    <xs:complexType name="wsData">
  <xs:sequence>
    <xs:element name="month" type="xs:string"/>
    <xs:element minOccurs="0" name="userLogin" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

    Valider mois avec son généré restriction (sans XmlAdapter).

    Vous pouvez définir une instance de Schema sur le Unmarshaller d'avoir l'avis validé:

    Démo

    Le code suivant peut être utilisé pour générer le schéma XML:

    package forum9111936;

import java.io.IOException;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.SchemaOutputResolver;
import javax.xml.transform.Result;
import javax.xml.transform.stream.StreamResult;

public class Demo {

    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(WSData.class);
        SchemaOutputResolver sor = new SchemaOutputResolver() {

            @Override
            public Result createOutput(String namespaceUri,
                    String suggestedFileName) throws IOException {
                StreamResult result = new StreamResult(System.out);
                result.setSystemId(suggestedFileName);
                return result;
            }

        };
        jc.generateSchema(sor);
        System.out.println();
    }

}

    Mise à JOUR

    La JAXB RI normalement jette un ValidationEvent de gravité 1 pour les problèmes de conversion. La valeur par défaut ValidationEventHandler ignore tous les problèmes d'une gravité inférieure à 2. Cela donne généralement la valeur null. Vous pouvez remplacer le ValidationEventHandler comme suit:

        unmarshaller.setEventHandler(new ValidationEventHandler() {
        @Override
        public boolean handleEvent(ValidationEvent event) {
            System.out.println(event);
            return event.getSeverity() < ValidationEvent.ERROR;
        }
    });

    Cependant la JAXB RI ne semble pas jeter les événements liés à la conversion des valeurs enum (bug possible). Si vous arrive d'être en utilisant EclipseLink JAXB (MOXy) que votre JAXB fournisseur alors vous aurez une exception comme:

    Exception in thread "main" Local Exception Stack: 
Exception [EclipseLink-116] (Eclipse Persistence Services - 2.4.0.qualifier): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: No conversion value provided for the value [13] in field [month/text()].
Mapping: org.eclipse.persistence.oxm.mappings.XMLDirectMapping[month-->month/text()]
Descriptor: XMLDescriptor(forum9111936.WSData --> [])
at org.eclipse.persistence.exceptions.DescriptorException.noFieldValueConversionToAttributeValueProvided(DescriptorException.java:1052)
at org.eclipse.persistence.mappings.converters.ObjectTypeConverter.convertDataValueToObjectValue(ObjectTypeConverter.java:140)
at org.eclipse.persistence.oxm.mappings.XMLDirectMapping.getAttributeValue(XMLDirectMapping.java:287)
at org.eclipse.persistence.internal.oxm.XMLDirectMappingNodeValue.endElement(XMLDirectMappingNodeValue.java:190)
at org.eclipse.persistence.oxm.record.UnmarshalRecord.endElement(UnmarshalRecord.java:910)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parseEvent(XMLStreamReaderReader.java:133)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parse(XMLStreamReaderReader.java:83)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parse(XMLStreamReaderReader.java:72)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(SAXUnmarshaller.java:838)
at org.eclipse.persistence.oxm.XMLUnmarshaller.unmarshal(XMLUnmarshaller.java:626)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:472)
at forum9111936.Demo2.main(Demo2.java:30)

    Pour Plus D'Informations

  3. 4

    Les fins de required et minOccurs ne sont pas induire en erreur, le problème est que la validation de schéma n'est pas activé. Juste permettre SchemaValidation à la WebService et définir l'ordre de la XmlType's de la cartographie comme suit:

    Service Web:

    @javax.jws.WebService
@org.jboss.ws.annotation.SchemaValidation(enabled = true)
public class WebServiceClass {
@javax.jws.WebMethod
public WSResponseData webServiceMethod() {
//...
}
}

    XmlType:

    @javax.xml.bind.annotation.XmlType(propOrder = {"field1", "field2", "field3"})
public class WSData {
//...
private String field1;
private Long field2;
private XmlMonthType field3;
//...
}
  4. 1

    En effet, il semble que les enveloppes SOAP ne sont pas validés à l'WSDL, ni sur le serveur ou le client.

    Et je pense que c'est mieux de cette façon. Validation consomme des ressources et du temps. Pour la plupart des WebServices, tous nous avons besoin avec WSDL est de fournir au client les définitions pour être en mesure de parler à un WebService, et de ne pas définir des restrictions comme si une propriété peut ou ne pas être null.

    Lorsque le serveur et le client sont sur le même PC, Axis2 ajoute 3 à 5 millisecondes de surcharge par rapport à des appels internes. Inutile de validation ne ferait qu'augmenter les frais généraux. J'ai de mieux à faire des opérations de lever une exception et valider manuellement ce qui est vraiment nécessaire.

  5. 1

    J'ai regardé dans le fichier XSD de la structure que vous avez posté, et de trouver que vous n'avez pas utilisé de type complexe que vous avez défini pour le mois , Insteqad de manipulation sur le code java vous pouvez parler de ce que tout dans XSD , et aussi le minOccur sur mois - élément dans votre type complexe est manquant . Veuillez utiliser le standered XSD pour java générateur , il va faire tous les fichier java tâche de génération pour vous

    The convention are as follow - 
MinOccur = 0 --> the element can be abscent in input , and can be present
MinOccur = 1 --> the element must be there in input
(but if you use it, then your java generated member will be of list type - list of ENUM for Int )
If you don't write MinOccur in attributes - then it makes the element mandatory , ( then you java generated member will be of simply ENUM for int )
MaxOccur = 1 --> minimum one element can be there in input 
(but if you use it, then your java generated member will be of list type - list of ENUM for Int )
MaxOccur = unbound --> only one element can be there in input 
(if you use it, then your java generated member will be of list type - list of ENUM for Int )
<xs:complexType name="wsData">
<xs:sequence>
<xs:element name="month" type="xmlMonthType" minOccurs="1" nillable="false" />
<xs:element name="userLogin" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="xmlMonthType">
<xs:restriction base="xs:int">
<xs:enumeration value="1"/>
<xs:enumeration value="2"/>
<xs:enumeration value="3"/>
<!-- ... months 4 ~9 ... -->
<xs:enumeration value="10"/>
<xs:enumeration value="11"/>
<xs:enumeration value="12"/>
</xs:restriction>
</xs:simpleType>