J'essaie de générer des classes Java à partir de la version 4.5 du FpML (Finanial Products Markup Language). Une tonne de code est généré, mais je ne peux pas l'utiliser. En essayant de sérialiser un document simple, j'obtiens ceci:

javax.xml.bind.MarshalException
  - with linked exception: [com.sun.istack.SAXException2: unable
  to marshal type
  "org.fpml._2008.fpml_4_5.PositionReport"
  as an element because it is missing an
  @XmlRootElement annotation]

En fait, aucune classe n'a l'annotation @XmlRootElement, alors que puis-je faire de mal?. Je pointe xjc (JAXB 2.1) vers fpml-main-4-5.xsd, qui inclut ensuite tous les types.

Pour lier ce que d'autres ont déjà déclaré ou laissé entendre, les règles selon lesquelles JAXB XJC décide de mettre ou non l' @XmlRootElementannotation sur une classe générée ne sont pas triviales ( voir cet article ).

@XmlRootElementexiste parce que le runtime JAXB nécessite certaines informations afin de marshaler / démarsaler un objet donné, en particulier le nom de l'élément XML et l'espace de noms. Vous ne pouvez pas simplement passer un vieil objet au Marshaller. @XmlRootElementfournit ces informations.

L'annotation n'est cependant qu'une commodité - JAXB n'en a pas besoin. L'alternative à est d'utiliser des JAXBElementobjets wrapper, qui fournissent les mêmes informations que @XmlRootElement, mais sous la forme d'un objet, plutôt que d'une annotation.

Cependant, les JAXBElementobjets sont difficiles à construire, car vous devez connaître le nom de l'élément XML et l'espace de noms, ce que la logique métier ne connaît généralement pas.

Heureusement, lorsque XJC génère un modèle de classe, il génère également une classe appelée ObjectFactory. Ceci est en partie là pour la compatibilité ascendante avec JAXB v1, mais c'est aussi là pour que XJC place des méthodes d'usine générées qui créent des JAXBElementwrappers autour de vos propres objets. Il gère le nom et l'espace de noms XML pour vous, vous n'avez donc pas à vous en préoccuper. Il vous suffit de parcourir les ObjectFactoryméthodes (et pour les grands schémas, il peut y en avoir des centaines) pour trouver celle dont vous avez besoin.

Ceci est mentionné au bas du billet de blog déjà lié ci-dessus, mais cela fonctionne comme un régal pour moi:

Marshaller marshaller = jc.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
marshaller.marshal(new JAXBElement<MyClass>(new QName("uri","local"), MyClass.class, myClassInstance), System.out);

Comme indiqué dans l'une des réponses ci-dessus, vous n'obtiendrez pas de XMLRootElement sur votre élément racine si dans le XSD son type est défini comme un type nommé, car ce type nommé pourrait être utilisé ailleurs dans votre XSD. Essayez de lui donner un type anonyme, c'est-à-dire au lieu de:

<xsd:element name="myRootElement" type="MyRootElementType" />

<xsd:complexType name="MyRootElementType">
...
</xsd:complexType>

tu aurais:

<xsd:element name="myRootElement">
    <xsd:complexType>
    ...
    <xsd:complexType>
</xsd:element>

@XmlRootElement n'est pas nécessaire pour unmarshalling - si l'on utilise la forme à 2 paramètres de Unmarshaller # unmarshall.

Donc, si au lieu de faire:

UserType user = (UserType) unmarshaller.unmarshal(new StringReader(responseString));

il faut faire:

JAXBElement<UserType> userElement = unmarshaller.unmarshal(someSource, UserType.class);
UserType user = userElement.getValue();

Ce dernier code ne nécessitera pas d'annotation @XmlRootElement au niveau de la classe UserType.

La réponse de Joe (Joe 26 juin 09 à 17:26) le fait pour moi. La réponse simple est que l'absence d'une annotation @XmlRootElement ne pose aucun problème si vous marshalez un JAXBElement. La chose qui m'a dérouté est que l'ObjectFactory généré a 2 méthodes createMyRootElement - la première ne prend aucun paramètre et donne l'objet non enveloppé, la seconde prend l'objet non enveloppé et le retourne enveloppé dans un JAXBElement, et la mise en forme que JAXBElement fonctionne bien. Voici le code de base que j'ai utilisé (je suis nouveau dans ce domaine, donc excuses si le code n'est pas formaté correctement dans cette réponse), largement extrait du texte du lien :

ObjectFactory objFactory = new ObjectFactory();
MyRootElement root = objFactory.createMyRootElement();
...
// Set root properties
...
if (!writeDocument(objFactory.createMyRootElement(root), output)) {
    System.err.println("Failed to marshal XML document");
}
...

private boolean writeDocument(JAXBElement document, OutputStream output) {

  Class<?> clazz = document.getValue().getClass();
  try {
    JAXBContext context =
        JAXBContext.newInstance(clazz.getPackage().getName());
    Marshaller m = context.createMarshaller();
    m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
    m.marshal(document, output);
    return true;

  } catch (JAXBException e) {
    e.printStackTrace(System.err);
    return false;
  }
}

Vous pouvez résoudre ce problème en utilisant la liaison de Comment générer des classes @XmlRootElement pour les types de base dans XSD? .

Voici un exemple avec Maven

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jaxb2-maven-plugin</artifactId>
            <version>1.3.1</version>
            <executions>
                <execution>
                    <id>xjc</id>
                    <goals>
                        <goal>xjc</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <schemaDirectory>src/main/resources/xsd</schemaDirectory>
                <packageName>com.mycompany.schemas</packageName>
                <bindingFiles>bindings.xjb</bindingFiles>
                <extension>true</extension>
            </configuration>
        </plugin>

Voici le binding.xjbcontenu du fichier

<?xml version="1.0"?>
<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
              xmlns:xjc= "http://java.sun.com/xml/ns/jaxb/xjc"
              jxb:extensionBindingPrefixes="xjc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <jxb:bindings schemaLocation="path/to/myschema.xsd" node="/xs:schema">
        <jxb:globalBindings>
            <xjc:simple/>
        </jxb:globalBindings>
    </jxb:bindings>
</jxb:bindings>

Comme vous le savez, la réponse consiste à utiliser ObjectFactory (). Voici un exemple du code qui a fonctionné pour moi :)

ObjectFactory myRootFactory = new ObjectFactory();

MyRootType myRootType = myRootFactory.createMyRootType();

try {

        File file = new File("./file.xml");
        JAXBContext jaxbContext = JAXBContext.newInstance(MyRoot.class);
        Marshaller jaxbMarshaller = jaxbContext.createMarshaller();

        //output pretty printed
        jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

        JABXElement<MyRootType> myRootElement = myRootFactory.createMyRoot(myRootType);

        jaxbMarshaller.marshal(myRootElement, file);
        jaxbMarshaller.marshal(myRootElement, System.out);

    } catch (JAXBException e) {
        e.printStackTrace();
    }

Cela ne fonctionne pas non plus pour nous. Mais nous avons trouvé un article largement cité qui ajoute QUELQUES antécédents ... Je vais le lier ici pour le bien de la prochaine personne: http://weblogs.java.net/blog/kohsuke/archive/2006/03 /why_does_jaxb_p.html

Après avoir traîné pendant deux jours, j'ai trouvé la solution au problème. Vous pouvez utiliser la classe ObjectFactory pour contourner les classes qui n'ont pas @XmlRootElement . ObjectFactory a surchargé les méthodes pour l'enrouler autour de JAXBElement.

Méthode: 1 fait la création simple de l'objet.

Méthode: 2 enveloppera l'objet avec @JAXBElement .

Utilisez toujours la méthode: 2 pour éviter javax.xml.bind.MarshalException - avec une exception liée manquant une annotation @XmlRootElement.

Veuillez trouver l'exemple de code ci-dessous

Méthode: 1 fait la création simple de l'objet

public GetCountry createGetCountry() {
        return new GetCountry();
    }

Méthode: 2 enveloppera l'objet avec @JAXBElement .

 @XmlElementDecl(namespace = "my/name/space", name = "getCountry")
 public JAXBElement<GetCountry> createGetCountry(GetCountry value) {
        return new JAXBElement<GetCountry>(_GetCountry_QNAME, GetCountry.class, null, value);
    }

Exemple de code de travail:

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
WebServiceTemplate springWSTemplate = context.getBean(WebServiceTemplate.class);

GetCountry request = new GetCountry();
request.setGuid("test_guid");

JAXBElement<GetCountryResponse> jaxbResponse = (JAXBElement<GetCountryResponse>)springWSTemplate .marshalSendAndReceive(new ObjectFactory().createGetCountry(request));

GetCountryResponse response = jaxbResponse.getValue();

Dans le cas où mon expérience de ce problème donne à quelqu'un un Eureka! moment .. je vais ajouter ce qui suit:

J'obtenais également ce problème, lorsque j'utilisais un fichier xsd que j'avais généré en utilisant l'option de menu "Générer xsd à partir d'un document d'instance" d'IntelliJ.

Lorsque j'ai accepté tous les paramètres par défaut de cet outil, il a généré un fichier xsd qui, lorsqu'il est utilisé avec jaxb, génère des fichiers java sans @XmlRootElement. Au moment de l'exécution, lorsque j'ai essayé de rassembler, j'ai eu la même exception que celle discutée dans cette question.

Je suis retourné à l'outil IntellJ et j'ai vu l'option par défaut dans la liste déroulante "Type de Desgin" (ce que bien sûr je ne comprenais pas .. et toujours pas si je suis honnête) était:

Type de conception:

"éléments locaux / types complexes globaux"

J'ai changé cela en

"éléments / types locaux"

, maintenant il a généré un xsd (sensiblement) différent, qui a produit le @XmlRootElementlorsqu'il est utilisé avec jaxb. Je ne peux pas dire que je comprends les avantages et les inconvénients, mais cela a fonctionné pour moi.

Avec une build Maven, vous pouvez ajouter le @XmlRootElement annotation

avec le jaxb2-basics-annotateplug-in " ".

Voir plus d'informations: voir

Configurer Maven pour générer des classes à partir du schéma XML à l'aide de JAXB

et génération de code JAXB XJC

Les wrappers JAXBElement fonctionnent pour les cas où aucun @XmlRootElementn'est généré par JAXB. Ces wrappers sont disponibles dans la ObjectFactoryclasse générée par maven-jaxb2-plugin. Par exemple:

     public class HelloWorldEndpoint {
        @PayloadRoot(namespace = NAMESPACE_URI, localPart = "person")
        @ResponsePayload
        public JAXBElement<Greeting> sayHello(@RequestPayload JAXBElement<Person> request) {

        Person person = request.getValue();

        String greeting = "Hello " + person.getFirstName() + " " + person.getLastName() + "!";

        Greeting greet = new Greeting();
        greet.setGreeting(greeting);

        ObjectFactory factory = new ObjectFactory();
        JAXBElement<Greeting> response = factory.createGreeting(greet);
        return response;
      }
 }

Avez-vous essayé de changer votre xsd comme ça?

<!-- create-logical-system -->
<xs:element name="methodCall">
  <xs:complexType>
    ...
  </xs:complexType>
</xs:element>

Pour le résoudre, vous devez configurer une liaison xml avant de compiler avec wsimport, en définissant generateElementProperty sur false.

     <jaxws:bindings wsdlLocation="LOCATION_OF_WSDL"
      xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
      xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
         <jaxws:enableWrapperStyle>false</jaxws:enableWrapperStyle>
    <jaxws:bindings  node="wsdl:definitions/wsdl:types/xs:schema[@targetNamespace='NAMESPACE_OF_WSDL']">
      <jxb:globalBindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb" xmlns:xs="http://www.w3.org/2001/XMLSchema">
            <xjc:generateElementProperty>false</xjc:generateElementProperty> 
      </jxb:globalBindings>
  </jaxws:bindings>
</jaxws:bindings>

Le sujet est assez ancien mais toujours pertinent dans les contextes d'entreprise. J'ai essayé d'éviter de toucher les xsds afin de les mettre à jour facilement à l'avenir. Voici mes solutions ..

1. Surtout xjc:simplesuffit

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jxb:bindings version="2.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    jxb:extensionBindingPrefixes="xjc">

    <jxb:globalBindings>
        <xjc:simple/> <!-- adds @XmlRootElement annotations -->
    </jxb:globalBindings>

</jxb:bindings>

Il créera principalement des XmlRootElements pour importer des définitions xsd.

2. Divisez vos jaxb2-maven-pluginexécutions

J'ai rencontré que cela fait une énorme différence si vous essayez de générer des classes à partir de plusieurs définitions xsd au lieu d'une définition d'exécution par xsd.

Donc, si vous avez une définition avec plusieurs <source>, essayez simplement de les diviser:

          <execution>
            <id>xjc-schema-1</id>
            <goals>
              <goal>xjc</goal>
            </goals>
            <configuration>
              <xjbSources>
                <xjbSource>src/main/resources/xsd/binding.xjb</xjbSource>
              </xjbSources>
              <sources>
                <source>src/main/resources/xsd/definition1/</source>
              </sources>
              <clearOutputDir>false</clearOutputDir>
            </configuration>
          </execution>

          <execution>
            <id>xjc-schema-2</id>
            <goals>
              <goal>xjc</goal>
            </goals>
            <configuration>
              <xjbSources>
                <xjbSource>src/main/resources/xsd/binding.xjb</xjbSource>
              </xjbSources>
              <sources>
                <source>src/main/resources/xsd/definition2/</source>
              </sources>
              <clearOutputDir>false</clearOutputDir>
            </configuration>
          </execution>

Le générateur n'acceptera pas le fait qu'une classe pourrait être suffisante et créera donc des classes personnalisées par exécution. Et c'est exactement ce dont j'ai besoin;).