Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger. 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 20 Einführung in <XML>
Pfeil 20.1 Auszeichnungssprachen
Pfeil 20.1.1 Die Standard Generalized Markup Language (SGML)
Pfeil 20.1.2 Extensible Markup Language (XML)
Pfeil 20.2 Eigenschaften von XML-Dokumenten
Pfeil 20.2.1 Elemente und Attribute
Pfeil 20.2.2 Beschreibungssprache für den Aufbau von XML-Dokumenten
Pfeil 20.2.3 Schema – die moderne Alternative zu DTD
Pfeil 20.2.4 Namensraum (Namespace)
Pfeil 20.2.5 XML-Applikationen *
Pfeil 20.3 Die Java-APIs für XML
Pfeil 20.3.1 Das Document Object Model (DOM)
Pfeil 20.3.2 Simple API for XML Parsing (SAX)
Pfeil 20.3.3 Pull-API StAX
Pfeil 20.3.4 Java Document Object Model (JDOM)
Pfeil 20.3.5 JAXP als Java-Schnittstelle zu XML
Pfeil 20.3.6 DOM-Bäume einlesen mit JAXP *
Pfeil 20.4 Java Architecture for XML Binding (JAXB)
Pfeil 20.4.1 Bean für JAXB aufbauen
Pfeil 20.4.2 Utility-Klasse JAXB
Pfeil 20.4.3 Ganze Objektgraphen schreiben und lesen
Pfeil 20.4.4 JAXBContext und Marshaller/Unmarshaller nutzen
Pfeil 20.4.5 Validierung
Pfeil 20.4.6 Weitere JAXB-Annotationen *
Pfeil 20.4.7 Beans aus XML-Schema-Datei generieren
Pfeil 20.5 XML-Dateien mit JDOM verarbeiten
Pfeil 20.5.1 JDOM beziehen
Pfeil 20.5.2 Paketübersicht *
Pfeil 20.5.3 Die Document-Klasse
Pfeil 20.5.4 Eingaben aus der Datei lesen
Pfeil 20.5.5 Das Dokument im XML-Format ausgeben
Pfeil 20.5.6 Der Dokumenttyp *
Pfeil 20.5.7 Elemente
Pfeil 20.5.8 Zugriff auf Elementinhalte
Pfeil 20.5.9 Liste mit Unterelementen erzeugen *
Pfeil 20.5.10 Neue Elemente einfügen und ändern
Pfeil 20.5.11 Attributinhalte lesen und ändern
Pfeil 20.5.12 XPath
Pfeil 20.6 Zum Weiterlesen
 

Zum Seitenanfang

20.4Java Architecture for XML Binding (JAXB) Zur vorigen ÜberschriftZur nächsten Überschrift

Java Architecture for XML Binding (JAXB) ist eine API zum Übertragen von Objektzuständen auf XML-Dokumente und umgekehrt. Anders als eine manuelle Abbildung von Java-Objekten auf XML-Dokumente oder das Parsen von XML-Strukturen und Übertragen der XML-Elemente auf Geschäftsobjekte arbeitet JAXB automatisch. Die Übertragungsregeln definieren Annotationen, die Entwickler selbst an die JavaBeans setzen können, aber JavaBeans werden gleich zusammen mit den Annotationen von einem Werkzeug aus einer XML-Schema-Datei generiert. JAXB läuft in anderen Versionsnummern als das JDK. Java 7 aktualisiert auf JAXB 2.2, die gleiche Version, die auch Java 8 hat.

 

Zum Seitenanfang

20.4.1Bean für JAXB aufbauen Zur vorigen ÜberschriftZur nächsten Überschrift

Wir wollen einen Player deklarieren, und JAXB soll ihn anschließend in ein XML-Dokument übertragen:

Listing 20.6com/tutego/insel/xml/jaxb/Player.java, Player

@XmlRootElement

class Player {



private String name;

private Date birthday;



public String getName() {

return name;

}



public void setName( String name ) {

this.name = name;

}



public void setBirthday( Date birthday ) {

this.birthday = birthday;

}



public Date getBirthday() {

return birthday;

}

}

Die Klassen-Annotation @XmlRootElement ist an der JavaBean nötig, wenn die Klasse das Wurzelelement eines XML-Baums bildet und Anpassungen am Namen gewünscht sind. Die Annotation stammt aus dem Paket javax.xml. bind.annotation.

 

Zum Seitenanfang

20.4.2Utility-Klasse JAXB Zur vorigen ÜberschriftZur nächsten Überschrift

Ein kleines Testprogramm baut eine Person auf und bildet sie dann in XML ab – die Ausgabe der Abbildung kommt auf den Bildschirm. Um ein Objekt in seine XML-Repräsentation zu bringen, lässt sich auf eine einfache statische marshal(…)-Methode der Utility-Klasse JAXB zurückgreifen:

Listing 20.7com/tutego/insel/xml/xml/jaxb/SimplePlayerMarshaller.java, main()

Player johnPeel = new Player();

johnPeel.setName( "John Peel" );

johnPeel.setBirthday( new GregorianCalendar(1939,Calendar.AUGUST,30).getTime() );

JAXB.marshal( johnPeel, System.out );

JAXB beachtet standardmäßig alle Bean-Properties, also birthday und name, und nennt die XML-Elemente nach den Properties:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<player>

<birthday>1939-08-30T00:00:00+01:00</birthday>

<name>John Peel</name>

</player>

Die marshal(…)-Methode schreibt das in XML transformierte Player-Objekt in unserem Beispiel in den Konsolenausgabestrom. Die JAXB-Klasse bietet daneben auch unmarshal(…)-Methoden, um das Objekt wiederherzustellen; das schauen wir uns im nächsten Beispiel an.

Falls das Schreiben oder Lesen misslingt, gibt es eine RuntimeException. Diese referenziert die intern geprüften Ausnahmen vom Typ DataBindingException.

class javax.xml.bind.JAXB
  • static void marshal(Object jaxbObject, File xml)

  • static void marshal(Object jaxbObject, OutputStream xml)

  • static void marshal(Object jaxbObject, Result xml)

  • static void marshal(Object jaxbObject, String xml)

  • static void marshal(Object jaxbObject, URI xml)

  • static void marshal(Object jaxbObject, URL xml)

  • static void marshal(Object jaxbObject, Writer xml)

    Schreibt das XML-Dokument in die angegebene Ausgabe. Im Fall von URI/URL wird ein HTTP-POST gestartet. Ist der Parametertyp String, wird er als URL gesehen und führt ebenfalls zu einem HTTP-Zugriff. Result ist ein Typ für eine XML-Transformation und wird später vorgestellt.

  • static <T> T unmarshal(File xml, Class<T> type)

  • static <T> T unmarshal(InputStream xml, Class<T> type)

  • static <T> T unmarshal(Reader xml, Class<T> type)

  • static <T> T unmarshal(Source xml, Class<T> type)

  • static <T> T unmarshal(String xml, Class<T> type)

  • static <T> T unmarshal(URI xml, Class<T> type)

  • static <T> T unmarshal(URL xml, Class<T> type)

    Rekonstruiert aus der gegebenen XML-Quelle den Java-Objektgraphen.

 

Zum Seitenanfang

20.4.3Ganze Objektgraphen schreiben und lesen Zur vorigen ÜberschriftZur nächsten Überschrift

JAXB bildet nicht nur das zu schreibende Objekt ab, sondern auch rekursiv alle referenzierten Unterobjekte. Wir wollen den Spieler dazu in einen Raum setzen und den Raum in XML abbilden. Dazu muss der Raum die Annotation @XmlRootElement bekommen, und bei Player kann sie entfernt werden, wenn nur der Raum selbst, aber keine Player als Wurzelobjekte zum Marshaller kommen:

Listing 20.8com/tutego/insel/xml/xml/jaxb/Room.java, Room

@XmlRootElement( namespace = "http://tutego.com/" )

public class Room {



private List<Player> players = new ArrayList<>();



@XmlElement( name = "player" )

public List<Player> getPlayers() {

return players;

}



public void setPlayers( List<Player> players ) {

this.players = players;

}

}

Zwei Annotationen kommen vor: Da Room der Start des Objektgraphen ist, trägt es @XmlRootElement. Als Erweiterung ist das Element namespace für den Namensraum gesetzt, da bei eigenen XML-Dokumenten immer ein Namensraum genutzt werden soll. Außerdem ist eine Annotation @XmlElement am Getter getPlayers() platziert, um den Namen des XML-Elements zu überschreiben, damit das XML-Element nicht <players> heißt, sondern <player>.

Kommen wir abschließend zu einem Beispiel, das einen Raum mit zwei Spielern aufbaut und diesen Raum dann in eine XML-Datei schreibt:

Listing 20.9com/tutego/insel/xml/jaxb/RoomMarshaller.java, main()

Player john = new Player();

john.setName( "John Peel" );



Player tweet = new Player();

tweet.setName( "Zwitscher Zoe" );



Room room = new Room();

room.setPlayers( Arrays.asList( john, tweet ) );



Path path = Paths.get( "room.xml" );

try ( Writer out = Files.newBufferedWriter( path, StandardCharsets.UTF_8 ) ) {

JAXB.marshal( room, out );

Room room2 = JAXB.unmarshal( path.toFile(), Room.class );

System.out.println( room2.getPlayers().get( 0 ).getName() ); // John Peel

}

catch ( IOException e ) {

e.printStackTrace();

}

Die Ausgabe ist:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ns2:room xmlns:ns2="http://tutego.com/">

<player>

<name>John Peel</name>

</player>

<player>

<name>Zwitscher Zoe</name>

</player>

</ns2:room>

Da beim Spieler das Geburtsdatum nicht gesetzt war (null wird referenziert), wird es auch nicht in XML abgebildet.

 

Zum Seitenanfang

20.4.4JAXBContext und Marshaller/Unmarshaller nutzen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Utility-Klasse JAXB verfügt ausschließlich über statische überladene marshal(…)- und unmarshal(…)-Methoden, ist aber in Wirklichkeit nur eine Fassade. Vielmehr ist JAXBContext das tatsächliche Ausgangsobjekt, und davon erfragt werden ein Marshaller zum Schreiben und ein Unmarshaller zum Lesen:

Listing 20.10com/tutego/insel/xml/xml/jaxb/PlayerMarshaller.java, main()

Player johnPeel = new Player();

johnPeel.setName( "John Peel" );

johnPeel.setBirthday( new GregorianCalendar(1939,Calendar.AUGUST,30).getTime() );

JAXBContext context = JAXBContext.newInstance( Player.class );

Marshaller m = context.createMarshaller();

m.setProperty( Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE );

m.marshal( johnPeel, System.out );

Die Ausgabe ist identisch mit der ersten:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<player>

<birthday>1939-08-30T00:00:00+01:00</birthday>

<name>John Peel</name>

</player>

Alles bei JAXB beginnt mit der zentralen Klasse JAXBContext. Die statische Methode JAXBContext.newInstance(Class…) erwartet standardmäßig eine Aufzählung der Klassen, die JAXB behandeln soll; die Klassennamen können auch voll qualifiziert über einen String angegeben werden mit newInstance(String). Der JAXBContext liefert den Marshaller zum Schreiben und den Unmarshaller zum Lesen. Die Fabrikmethode createMarshaller() gibt dabei einen Schreiberling, der mit marshal(Object, …) das Wurzelobjekt in einen Datenstrom schreibt. Das zweite Argument von marshal(Object, …) ist unter anderem ein OutputStream (wie System.out in unserem Beispiel), Writer oder File-Objekt.

class javax.xml.bind.JAXBContext
  • static JAXBContext newInstance(Class... classesToBeBound) throws JAXBException

    Liefert ein Exemplar vom JAXBContext mit Klassen, die als Wurzelklassen für JAXB verwendet werden können.

  • abstract Marshaller createMarshaller()

    Erzeugt einen Marshaller, der Java-Objekte in XML-Dokumente konvertieren kann.

  • abstract Unmarshaller createUnmarshaller()

    Erzeugt einen Unmarshaller, der XML-Dokumente in Java-Objekte konvertiert.

class javax.xml.bind.Marshaller
  • void marshal(Object jaxbElement, File output)

  • void marshal(Object jaxbElement, OutputStream os)

  • void marshal(Object jaxbElement, Writer writer)

    Schreibt den Objektgraphen von jaxbElement in eine Datei oder einen Ausgabestrom.

  • void marshal(Object jaxbElement, Node node)

    Erzeugt vom Objekt einen DOM-Knoten. Dieser kann dann in ein XML-Dokument gesetzt werden.

  • void marshal(Object jaxbElement, XMLEventWriter writer)

  • void marshal(Object jaxbElement, XMLStreamWriter writer)

    Erzeugt für ein jaxbElement einen Informationsstrom für den XMLEventWriter bzw. XMLStreamWriter; das sind spezielle StAX-Klassen.

  • void setProperty(String name, Object value)

    Setzt eine Eigenschaft der Marshaller-Implementierung. Eine Einrückung etwa setzt das Paar Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE.

Der Unmarshaller bietet über zehn Varianten von unmarshal(…), unter anderem mit den Parametertypen File, InputSource, InputStream, Node, Reader, URL, XMLEventReader.

Tipps und Tricks mit JAXBContext

Den JAXBContext aufzubauen kostet Zeit und Speicher. Er sollte daher für wiederholte Operationen gespeichert werden. Noch eine Information: Marshaller und Unmarshaller sind nicht threadsicher; es darf keine zwei Threads geben, die gleichzeitig den Marshaller/Unmarshaller nutzen.

Die unmarshal(…)-Methode ist überladen mit Parametern, die typische Datenquellen repräsentieren, etwa Dateien oder Eingabeströme wie ein Reader. Allerdings sind noch andere Parametertypen interessant, und es lohnt sich, hier einmal in die API-Dokumentation zu schauen. Ein spannender Typ ist javax.xml.transform.Source bzw. die Implementierung der Schnittstelle durch JAXBSource. JAXBSource ist die Quelle, aus der JAXB seine Informationen bezieht, um ein neues Java-Objekt zu rekonstruieren.

Das nächste Beispiel nimmt sich das aus dem vorangehenden Beispiel aufgebaute Objekt room als Basis und erzeugt eine tiefe Kopie davon:

Listing 20.11com/tutego/insel/xml/xml/jaxb/RoomCopy.java, main(), Ausschnitt

Room room = …

JAXBContext context = JAXBContext.newInstance( Room.class );

Unmarshaller unmarshaller = context.createUnmarshaller();

JAXBSource source = new JAXBSource( context, room );

Room copiedRoom = Room.class.cast( unmarshaller.unmarshal( source ) );

System.out.println( copiedRoom.getPlayers() ); // com.tutego.insel.xml.jaxb.Player@...]

Das Beispiel zeigt somit, wie sich mithilfe von JAXB Objektkopien erzeugen lassen.

 

Zum Seitenanfang

20.4.5Validierung Zur vorigen ÜberschriftZur nächsten Überschrift

Beim Schreiben und auch beim Lesen von XML-Dokumenten kann JAXB diese gegen ein XML-Schema validieren:

  • Falsche XML-Dokumente sollen nicht eingelesen werden. Wenn die Schema-Datei zum Beispiel vorschreibt, dass eine Zahl (etwa für die Bohrtiefe) nur im Wertebereich von 0 bis 10.000 liegen darf, und in einer XML-Datei taucht dann ein Wert von 10.600 auf, dann wäre die XML-Datei nach diesem Schema nicht valide. JAXB sollte sie ablehnen.

  • Falsche Werte in JavaBeans dürfen nicht zu nichtvaliden XML-Dokumenten führen. JavaBeans bestehen aus einfachen Settern und Gettern, und die Prüfungen im XML-Schema gehen weit über das hinaus, was üblicherweise eine JavaBean prüft. So kann eine Schema-Definition etwa vorschreiben, dass eine Zeichenkette nach einem ganz speziellen regulären Ausdruck geschrieben wird. In der Regel sind die Setter aber nicht so implementiert, dass sie die Strings direkt prüfen. JAXB sollte es auch nicht erlauben, dass JavaBeans mit falschen Strings geschrieben werden und zu nichtvaliden XML-Dokumenten führen können.

Zentral bei der Validierung ist eine XML-Schema-Datei. Doch wo kommt diese her? Wurden aus der Schema-Datei die JavaBeans generiert, ist logischerweise die Schema-Beschreibung schon da. Sind die JavaBeans aber zuerst da, gibt es erst einmal keine Schema-Datei. Über unterschiedliche Wege lässt sich eine passende Schema-Datei entwickeln:

  • Per Hand: Die XML-Schema-Datei wird per Hand selbstständig ohne Tool entwickelt.

  • Über die XML-Dokumente: Ein Tool analysiert XML-Dateien und erzeugt anhand der erkannten Strukturen eine XML-Schema-Datei. Für dieses Verfahren gibt es eine Reihe von Tools, und einige sind auch online verfügbar, etwa http://tutego.de/go/xml-2-xsd.

  • Mit schemagen: Das JDK bringt ein Tool mit dem Namen schemagen mit, das auf JAXB-annotierte Beans angesetzt wird und die Schema-Datei generiert.

Mit schemagen aus JAXB-Beans eine XML-Schema-Datei generieren

Das Tool schemagen befindet sich wie alle anderen JDK-Tools im bin-Verzeichnis. Das Kommandozeilentool erwartet die Angabe einer Quellcodeklasse oder einer compilierten Klasse und spuckt die Schema-Beschreibungen aus. Kapseln wir das in ein Skript:

Listing 20.12room-schemagen.bat

@echo off

PATH=%PATH%;C:\Program Files\Java\jdk1.8.0\bin

schemagen com.tutego.insel.xml.jaxb.Room

Und rufen wir es auf:

$ room-schemagen.bat

Note: Writing C:\...\schema1.xsd

Note: Writing C:\...\schema2.xsd

Das Tool erzeugt zwei Schema-Dateien, und sie sehen so aus:

Listing 20.13schema1.xsd

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<xs:schema version="1.0" targetNamespace="http://tutego.com/"

xmlns:xs="http://www.w3.org/2001/XMLSchema">



<xs:import schemaLocation="schema2.xsd" />



<xs:element name="room" type="room" />



</xs:schema>

Listing 20.14schema2.xsd

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">



<xs:element name="player" type="player" />



<xs:complexType name="room">

<xs:sequence>

<xs:element ref="player" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence>

</xs:complexType>



<xs:complexType name="player">

<xs:sequence>

<xs:element name="birthday" type="xs:dateTime" minOccurs="0" />

<xs:element name="name" type="xs:string" minOccurs="0" />

</xs:sequence>

</xs:complexType>

</xs:schema>

Ein genaues Verständnis des Schemas ist nicht nötig.

Visualisierung des Schemas

Abbildung 20.1Visualisierung des Schemas

Schema-Validierung mit JAXB

Wir wollen die Validierungsmöglichkeiten von JAXB für unsere bekannte Raumdatei ausprobieren und bewusst zwei Fehler einbauen (siehe Tabelle 20.4).

Valide XML-Datei (nach Schema)

Nichtvalide XML-Datei (nach Schema)

Listing 20.15room.xml

<?xml version="1.0" encoding="UTF-8"?>

<ns2:room xmlns:ns2="http://tutego.com/">

<player>

<name>John Peel</name>

</player>

<player>

<name>Zwitscher Zoe</name>

</player>

</ns2:room>

Listing 20.16room-invalid.xml

<?xml version="1.0" encoding="UTF-8"?>

<room>

<player>

<name>John Peel</name>

</player>

<player>

<name>Zwitscher Zoe</name>

<name>Heini Hayward</name>

</player>

</room>

Tabelle 20.4Nach dem Schema valide und nichtvalide XML-Datei

Das Java-Programm aus dem vorigen Abschnitt schrieb eine korrekte XML-Datei room.xml. In room-invalid.xml fehlt einmal der Namensraum, und dann sind zwei Namen angegeben, obwohl die Schema-Datei nur einen Namen erlaubt.

Damit JAXB den Fehler erkennt, muss es mit der neuen Schema-Datei verbunden werden. JAXP hat eine eigene API für Validierungen, die dafür eingesetzt wird:

Listing 20.17com/tutego/insel/xml/jaxb/ValidatingRoomUnmarshaller.java, main()

JAXBContext context = JAXBContext.newInstance( Room.class );

Unmarshaller unmarshaller = context.createUnmarshaller();

SchemaFactory sf = SchemaFactory.newInstance( W3C_XML_SCHEMA_NS_URI );

Schema schema = sf.newSchema(

ValidatingRoomUnmarshaller.class.getResource( "/schema1.xsd" ) );

unmarshaller.setSchema( schema );

URL url = Paths.get( "invalid-room.xml" ).toUri().toURL();

Room room = (Room) unmarshaller.unmarshal( url );

System.out.println( room.getPlayers() );

Es wird ein Exemplar eines Schema-Objekts erzeugt, und dieses wird über setSchema(Schema) beim Unmarshaller gesetzt. (Achtung: JAXB.unmarshal(file, Room.class) wird nicht funktionieren!)

Schon der erste Fehler in invalid-room.xml führt zum Abbruch:

Exception in thread "main" javax.xml.bind.UnmarshalException

– with linked exception:

[org.xml.sax.SAXParseException; systemId: X

file:/C:/Insel/programme/18_XML/invalid-room.xml; lineNumber: 2; columnNumber: 7; ¿

cvc-elt.1: Cannot find the declaration of element 'room'.]

Ist der Fehler behoben, kommt das zweite Problem zum Tragen, nämlich der Umstand, dass es zwei Namen gibt:

Exception in thread "main" javax.xml.bind.UnmarshalException

– with linked exception:

[org.xml.sax.SAXParseException; systemId: ¿

file:/C:/Insel/programme/18_XML/invalid-room.xml; lineNumber: 8; columnNumber: 11; ¿

cvc-complex-type.2.4.d: Invalid content was found starting with element 'name'. ¿

No child element is expected at this point.]

Erst wenn der Fehler behoben wurde, gibt es keine Ausnahme mehr, und JAXB gibt Ruhe.

 

Zum Seitenanfang

20.4.6Weitere JAXB-Annotationen * Zur vorigen ÜberschriftZur nächsten Überschrift

XML-Schemas können recht komplex werden, sodass auch die Anzahl der JAXB-Annotationen und Möglichkeiten hoch ist. Im Folgenden sollen verschiedene JAXB-Annotationen ihre Wirkung auf die XML-Ausgaben zeigen.

Zugriff über Setter/Getter oder Attribute

JAXB kann die Werte über JavaBean-Properties – also Setter/Getter – setzen und lesen und/oder direkt auf die Attribute zugreifen. Der Attributzugriff ist vergleichbar mit der Standardserialisierung, und der Zugriff über die Property ist von der JavaBeans Persistence über java.beans.XMLEncoder/java.beans.XMLDecoder realisiert. Welchen Weg JAXB gehen soll, bestimmt die Annotation @XmlAccessorType, die üblicherweise an der Klasse festgemacht wird. Drei Werte sind interessant:

Wert

Datenaustausch über

@XmlAccessorType(XmlAccessType.FIELD)

jedes nichtstatische Attribut

@XmlAccessorType(XmlAccessType.PROPERTY)

jede JavaBean-Property

@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)

jede öffentliche JavaBean-Property oder jedes öffentliche Attribut

Tabelle 20.5Womit JAXB die Daten austauscht

Die Standardbelegung ist AccessType.PUBLIC_MEMBER.

@Transient

Die Annotation @Transient nimmt ein Element von der XML-Abbildung aus. Das ist nützlich für den XmlAccessType.FIELD oder XmlAccessType.PROPERTY, da dann auch private Eigenschaften geschrieben werden, was allerdings nicht in jedem Fall erwünscht ist:

Java-Beispiel

XML-Ergebnis

class Person {

@XmlTransient public int id;

public String firstname;

public String lastname;

}
<person>

<firstname>Christian</firstname>

<lastname>Ullenboom</lastname>

</person>

Tabelle 20.6Beispiel für @Transient und Ergebnis

Werte als Attribute schreiben mit @XmlAttribute

Üblicherweise schreibt JAXB jeden Wert in ein eigenes XML-Element. Soll der Wert als Attribut geschrieben werden, kommt die Annotation @XmlAttribute zum Einsatz:

Java-Beispiel

XML-Ergebnis

class Person {

public String name;

public @XmlAttribute int id;

}
<person id="123">

<name>Christian</name>

</person>

Tabelle 20.7Beispiel für @XmlAttribute und Ergebnis

Reihenfolge der Elemente ändern

Ist die Reihenfolge der XML-Elemente wichtig, so lässt sich mit dem propOrder von @XmlType die Reihenfolge der Eigenschaften bestimmen:

Java-Beispiel

XML-Ergebnis

class Person {

public String lastname,

firstname;

}
<person>

<lastname>Ullenboom</lastname>

<firstname>Christian</firstname>

</person>
@XmlType(

propOrder = { "firstname", "lastname" }

)

class Person {

public String lastname, firstname;

}
<person>

<firstname>Christian</firstname>

<lastname>Ullenboom</lastname>

</person>

Tabelle 20.8XML-Abbildung ohne und mit @XmlType(propOrder…)

Einzelner Wert ohne eigenes XML-Element

Gibt es nur ein Element in der Klasse, so kann @XmlValue es direkt ohne Unterelement in den Rumpf setzen:

Java-Beispiel

XML-Ergebnis

class Person {

public int id;

}
<person>

<id>123</id>

</person>
class Person {

public @XmlValue int id;

}
<person>123</person>

Tabelle 20.9XML-Abbildung mit @XmlValue

Kompakte Listendarstellung

Die Datenstruktur Liste wird in JAXB üblicherweise so abgebildet, dass jedes Listenelement einzeln in ein XML-Element kommt. Die Annotation @XmlList weist JAXB an, Elemente einer Sammlung mit Leerzeichen zu trennen. Das funktioniert gut bei IDs, aber natürlich nicht mit allgemeinen Zeichenketten, die Leerzeichen enthalten:

Java-Beispiel

XML-Ergebnis

class Person {

public List<String> emails;

}
<person>

<emails>muh@kuh.de</emails>

<emails>zick@zak.com</emails>

</person>
class Person {

public @XmlList List<String> emails;

}
<person>

<emails>muh@kuh.de zick@zak.com</emails>

</person>

Tabelle 20.10Beispiel für @XmlList

Elemente zusätzlich einpacken

Die Annotation @XmlElementWrapper dient dazu, ein zusätzliches XML-Element zu erzeugen. In der Regel wird das für Sammlungen angewendet, wie auch das folgende Beispiel zeigt:

Java-Beispiel

XML-Ergebnis

class Person {

public List<String> emails;

}
<person>

<emails>muh@kuh.de</emails>

<emails>zick@zack.com</emails>

</person>
class Person {

@XmlElementWrapper(name = "emails")

@XmlElement(name = "email")

public List<String> emails;

}
<person>

<emails>

<email>muh@kuh.de</email>

<email>zick@zack.com</email>

</emails>

</person>

Tabelle 20.11Beispiel für @XmlElementWrapper/@XmlElement

Anpassen der XML-Abbildung

Nicht immer passt die Standardabbildung eines Datentyps gut. Für Farben sollen zum Beispiel nicht die Rot-, Grün- und Blauwerte einzeln geschrieben werden, sondern alles kompakt in einem String. Auch die Standardabbildung für Datumswerte trifft nicht jeden Geschmack:

Java-Beispiel

XML-Ergebnis

class Person {

public Date birthday;

}
<person>

<birthday>1973-03-12T00:00:00+01:00</birthday>

</person>

Tabelle 20.12Standard-XML-Abbildung eines Datums

Für Aufgaben dieser Art erlaubt die Annotation @XmlJavaTypeAdapter die Angabe einer Konverterklasse, die einmal den Weg vom Objekt in eine String-Repräsentation für das XML-Element und dann vom String in das Objekt zurück beschreibt:

class Person {

@XmlJavaTypeAdapter( DateAdapter.class )

public Date birthday;

}

Die eigene Klasse DateAdapter erweitert die vorgegebene JAXB-Klasse XmlAdapter und überschreibt zwei Methoden für beide Konvertierungswege:

class DateAdapter extends XmlAdapter<String, Date> {

private final static DateFormat formatter = new SimpleDateFormat( "dd/MM/yyyy" );



public Date unmarshal( String date ) throws ParseException {

return formatter.parse( date );

}



public String marshal( Date date ) {

return formatter.format( date );

}

}

Damit bekommt die Ausgabe das gewünschte Format:

<person>

<birthday>12/03/1973</birthday>

</person>
abstract class javax.xml.bind.annotation.adapters.XmlAdapter<ValueType,BoundType>
  • abstract ValueType marshal(BoundType v)

    Konvertiert v in einen Werttyp, der dann in eine XML-Repräsentation überführt wird.

  • abstract BoundType unmarshal(ValueType v)

    Überführt den Wert in den XML-Typ.

ValueType und BoundType sind Typvariablen, aber ungewöhnlicherweise sind es keine einfachen Großbuchstaben.

Der spezielle Datentyp XMLGregorianCalendar

Neben der Möglichkeit, Datumswerte mit einem @XmlJavaTypeAdapter/XmlAdapter zu übersetzen, bietet JAXB den speziellen abstrakten Datentyp XMLGregorianCalendar. Die Abbildung in XML ist kompakter:

Java-Beispiel

XML-Ergebnis

class Person {

public XMLGregorianCalendar birthday;

}
<person>

<birthday>1973-03-12</birthday>

</person>

Tabelle 20.13Standardabbildung von XMLGregorianCalendar

XMLGregorianCalendar wird auch automatisch von dem Werkzeug xjc genutzt, wenn in der XML-Schema-Datei ein Datum vorkommt. Nicht ganz einfach sind die Erzeugung eines XMLGregorianCalendar-Objekts und die Belegung – hier gibt es noch Potenzial für Verbesserungen:

Person p = new Person();

GregorianCalendar c = new GregorianCalendar( 1973, Calendar.MARCH, 12 );

XMLGregorianCalendar gc = DatatypeFactory.newInstance().newXMLGregorianCalendar( c );

gc.setTimezone( DatatypeConstants.FIELD_UNDEFINED );

gc.setTime( DatatypeConstants.FIELD_UNDEFINED,

DatatypeConstants.FIELD_UNDEFINED,

DatatypeConstants.FIELD_UNDEFINED );

p.birthday = gc;

Die abstrakte Klasse DatatypeFactory bietet weitere statische Methoden für Mapper-Objekte, die XML in Objekte überführen oder umgekehrt:

abstract class javax.xml.datatype.DatatypeFactory
  • static DatatypeFactory newInstance()

    Liefert eine DatatypeFactory-Implementierung.

  • abstract XMLGregorianCalendar newXMLGregorianCalendar()

    Liefert einen XMLGregorianCalendar, bei dem alle Werte undefiniert sind.

  • abstract XMLGregorianCalendar newXMLGregorianCalendar(GregorianCalendar cal)

  • XMLGregorianCalendar newXMLGregorianCalendarDate(int year, int month, int day,

    int timezone)

  • XMLGregorianCalendar newXMLGregorianCalendarTime(int hours, int minutes, int seconds, int timezone)

  • XMLGregorianCalendar newXMLGregorianCalendarTime(int hours, int minutes,

    int seconds, BigDecimal fractionalSecond, int timezone)

  • XMLGregorianCalendar newXMLGregorianCalendar(int year, int month, int day, int hour,

    int minute, int second, int millisecond, int timezone)

  • abstract XMLGregorianCalendar newXMLGregorianCalendar(BigInteger year, int month, int day, int hour, int minute, int second, BigDecimal fractionalSecond, int timezone)

    Liefert ein XMLGregorianCalendar-Objekt mit unterschiedlichen Vorbelegungen.

Des Weiteren gibt es newDuration(…)-Methoden, die javax.xml.datatype.Duration-Objekte liefern. Die Duration-Objekte können zu XMLGregorianCalendar addiert werden bzw. repräsentieren in XML-Schema-Dateien den Typ xs:duration.

[zB]Beispiel

Eine XML-Schema-Datei soll für das Element period eine Dauer definieren:

<xs:element name="period" type="xs:duration"/>

Angewendet kann es so aussehen, um die Dauer von einem Jahr und einem Monat anzugeben:

<period>P1Y1M</period>

Werden aus Schema-Dateien die JavaBeans automatisch generiert, wird Duration für xs:duration eingesetzt.

Hierarchien einsetzen

Die XML-Abbildung von Objekten, die in Klassenbeziehungen organisiert sind, bedarf einer besonderen Vorbereitung. Nehmen wir an, Player und Key sind zwei Klassen, die von GameObject abgeleitet sind (eine Schnittstelle wäre für JAXB auch möglich). Unser Ziel ist es, Spieler und Schlüssel in einen Raum zu setzen:

abstract class GameObject {

public String name;

}



@XmlRootElement public class Player extends GameObject { }



@XmlRootElement public class Key extends GameObject {

public int id;

}

Zunächst gilt, dass die konkreten Klassen die Annotation @XmlRootElement tragen müssen. Ein Beispielraum soll einen Spieler und einen Schlüssel beherbergen:

Player player= new Player();

player.name = "Chris";



Key key = new Key();

key.name = "Entretenimiento";

key.id = 12;



Room room = new Room();

room.objects.add( key );

room.objects.add( player );

Der Raum referenziert in einer Liste allgemeine Objekte vom Typ GameObject. Nun reicht im Room ein einfaches

public List<GameObject> objects = new ArrayList<>();

zum Halten der Objektverweise aber nicht aus! Beim Verarbeiten würde JAXB die Information fehlen, welches Element denn tatsächlich in der Liste ist, denn ein Player sollte ja etwa durch <player> beschrieben sein und ein Schlüssel durch <key>. Die Abbildung kann nicht <objects> lauten, denn beim Lesen muss ein konkreter Untertyp rekonstruiert werden; wenn JAXB beim Lesen ein <objects> sieht, weiß es erst einmal nicht, ob ein Player oder ein Key zu erzeugen und in die Liste zu hängen ist. Das Ziel ist aber die folgende Abbildung:

<room>

<key>

<name>Entretenimiento</name>

<id>12</id>

</key>

<player>

<name>Chris</name>

</player>

</room>

Die Lösung liegt in der Anwendung der Annotationen @XmlElementRefs und @XmlElementRef. Ersteres ist ein Container, und das Zweite bestimmt den Typ, der in der Liste zu erwarten ist:

@XmlRootElement public class Room {

@XmlElementRefs( {

@XmlElementRef( type = Player.class ),

@XmlElementRef( type = Key.class ),

} )

public List<GameObject> objects = new ArrayList<GameObject>();

}

Mit diesem Hinweis berücksichtigt JAXB den Typ der Kinder und schreibt nicht einfach <objects>. Die Elementtypen in der Sammlung sind von uns mit @XmlRootElement annotiert und geben den Namen der XML-Elemente »player« und »key« vor (wir hätten natürlich mit so etwas wie @XmlRootElement(name="sportsman") den XML-Elementnamen überschreiben können).

 

Zum Seitenanfang

20.4.7Beans aus XML-Schema-Datei generieren Zur vorigen ÜberschriftZur nächsten Überschrift

Da es für existierende XML-Dateien mühselig ist, die annotierten JavaBeans von Hand aufzubauen, gibt es einen Generator, genannt Java Architecture for XML Binding Compiler, kurz xjc. Er kann von der Kommandozeile, vom Ant-Skript oder auch von Entwicklungsumgebungen aus aufgerufen werden. Er nimmt eine XML-Schema-Datei und generiert die Java-Klassen und eine ObjectFactory, die als – wie der Name schon sagt – Fabrik für die gemappten Objekte aus den XML-Elementen fungiert.

xjc aufrufen

Im ersten Schritt wechseln wir auf die Kommandozeile und testen entweder, ob das bin-Verzeichnis vom JDK im Suchpfad ist, oder wir wechseln in das bin-Verzeichnis, sodass wir xjc direkt aufrufen können, und folgende Ausgabe erscheint:

$ xjc



Usage: xjc [-options ...] <schema file/URL/dir/jar> ... [-b <bindinfo>] ...

If dir is specified, all schema files in it will be compiled.

If jar is specified, /META-INF/sun-jaxb.episode binding file will be compiled.

Options:

-nv : do not perform strict validation of the input schema(s)

-extension : allow vendor extensions – do not strictly follow the

Compatibility Rules and App E.2 from the JAXB Spec

-b <file/dir> : specify external bindings files (each <file> must have its own -b)

If a directory is given, **/*.xjb is searched

-d <dir> : generated files will go into this directory

-p <pkg> : specifies the target package

-httpproxy <proxy> : set HTTP/HTTPS proxy. Format is [user[:password]@]

proxyHost:proxyPort

-httpproxyfile <f> : Works like -httpproxy but takes the argument in a file to

protect password

-classpath <arg> : specify where to find user class files

-catalog <file> : specify catalog files to resolve external entity references

support TR9401, XCatalog, and OASIS XML Catalog format.

-readOnly : generated files will be in read-only mode

-npa : suppress generation of package level annotations

(**/package-info.java)

-no-header : suppress generation of a file header with timestamp

-target (2.0|2.1) : behave like XJC 2.0 or 2.1 and generate code that doesnt use

any 2.2 features.

-enableIntrospection : enable correct generation of Boolean getters/setters to

enable Bean Introspection apis

-contentForWildcard : generates content property for types with multiple

xs:any derived elements

-xmlschema : treat input as W3C XML Schema (default)

-relaxng : treat input as RELAX NG (experimental,unsupported)

-relaxng-compact : treat input as RELAX NG compact syntax (experimental, unsupported)

-dtd : treat input as XML DTD (experimental,unsupported)

-wsdl : treat input as WSDL and compile schemas inside it

(experimental,unsupported)

-verbose : be extra verbose

-quiet : suppress compiler output

-help : display this help message

-version : display version information

-fullversion : display full version information



Extensions:

-Xinject-code : inject specified Java code fragments into the generated code

-Xlocator : enable source location support for generated code

-Xsync-methods : generate accessor methods with the 'synchronized' keyword

-mark-generated : mark the generated code as @javax.annotation.Generated

-episode <FILE> : generate the episode file for separate compilation

Eigentlich ist bis auf die Angabe der Schema-Quelle (aus einer Datei oder alternativ die URL) keine weitere Angabe nötig. Es ist aber praktisch, zwei Optionen zu setzen: -p bestimmt das Java-Paket für die generierten Klassen und -d das Ausgabeverzeichnis, in dem der Generator die erzeugten Dateien ablegt.

Konflikte in der Schema-Datei *

Leider haben viele XML-Schemas ein Problem, sodass sie nicht direkt vom Schema-Compiler verarbeitet werden können. Ein Beispiel zeigt das Dilemma:

<container>

<head><content title="Titel"/></head>

<body><content doc="doc.txt"/></body>

</container>

In der hierarchischen Struktur heißt das in <head> und <body> vorkommende XML-Element gleich, nämlich content. Die Schema-Datei kann widerspruchslos definieren, dass die beiden XML-Elemente gleich heißen, aber unterschiedliche Attribute erlauben, sozusagen der Head-Content und das Body-Content. Allein durch ihre Hierarchie, also dadurch, dass sie einmal unter head und einmal unter body liegen, sind sie eindeutig bestimmt. Der Schema-Compiler von Java bekommt aber Probleme, da er diese hierarchische Information in eine flache bringt. Er kann einfach eine Klasse Head und Body aufbauen, aber bei <content> steht er vor einem Problem. Da die Schema-Definitionen unterschiedlich sind, müssten zwei verschiedene Java-Klassen unter dem gleichen Namen Content generiert werden. Das geht nicht, und xjc bricht mit Fehlern ab.

Fehler dieser Art gibt es leider häufig, und sie sind der Grund, warum aus vielen Schemas nicht einfach JavaBeans generiert werden können. Erfolglos ohne weitere Einstellungen sind beispielsweise DocBook, Office Open XML, SVG, MathML und weitere. Doch was könnte die Lösung sein? xjc sieht Konfigurationsdateien vor, die das Mapping anpassen können. In diesen Mapping-Dokumenten identifiziert ein XPath-Ausdruck die problematische Stelle und gibt einen Substitutionstyp an. Die Dokumentation auf der JAXB-Website weist Interessierte in die richtige Richtung.

JAXB-Plugins

Auf der Webseite http://java.net/projects/jaxb2-commons gibt es eine Reihe nützlicher zusätzlicher Plugins für JAXB. Zu ihnen gehören:

  • JAXB2 Basic Plugins: Diese Plugin-Sammlung besteht aus Equals (erzeugt die equals(…)-Methode, wobei der Gleichheitstest über ein Equals-Strategie-Objekt austauschbar ist), HashCode (erzeugt hashCode(), wobei auch hier die Berechnung des Hashwerts über ein Strategie-Objekt erfolgt), ToString (erzeugt toString(), auch wieder über ein externes ToStringStrategy-Objekt), Copyable (erzeugt copyTo(…), um Objektzustände in ein anderes typkompatibles Objekt zu kopieren, und auch clone(); arbeitet dabei mit CopyStrategie), Mergeable (realisiert mergeFrom(…)-Methoden mit MergeStrategy-Objekten, die Zustände eines anderen Objekts mit den eigenen vereinen), JAXBIndex (generiert eine jaxb.index-Datei, die alle generierten Schema-Klassen auflistet), Inheritance und AutoInheritance (erlauben JAXB-Beans, globale Elemente oder komplexe Typen von gewünschten Basisklassen zu erben oder Schnittstellen zu implementieren), Wildcard (spezifiziert, wie sich die Wildcard-Property verhalten soll), Setters (etwas andere Setter-Implementierung bei Sammlungen) und Simplify Plugin (komplexe Properties in Einzel-Properties aufspalten).

  • Camelcase Always Plugin: Sind die Elementnamen großgeschrieben, so wird JAXB automatisch großgeschriebene Properties umsetzen, sodass etwa aus NAME das Setter/Getter-Paar setNAME(…) und getNAME() entsteht. Das Plugin verhindert dies und nennt die Setter/Getter wie gewohnt setName(…) und getName().

  • Value-Constructor Plugin: Jede JavaBean bekommt von xjc nur einen Standard-Konstruktor. Das Plugin gibt einen weiteren Konstruktor hinzu, der alle Attribute direkt initialisiert.

  • Default Value Plugin: Ein XML-Schema kann mit defaultValue vordefinierte Initialbelegungen für Attribute angeben. xjc ignoriert diese. Das Plugin wertet diese Vorbelegungen aus und initialisiert die Attribute der JavaBean gemäß den Werten.

  • Property Change Listener Injector Plugin: Eine über xjc generierte JavaBean schreibt einen bei setXXX(…) übergebenen Wert direkt in das private Attribut durch. Mit dem Plugin wird ein VetoableChangeListener eingeführt, der gegen Wertänderungen votieren kann.

  • Fluent API Plugin: Anstatt eine Bean nur mit Setter-Aufrufen zu initialisieren, etwa eine Person mit setName(…) und setAge(…), generiert das Fluent API Plugin kaskadierbare Methoden, sodass im Beispiel unserer Person nur new Person().withName(…).withAge(…) zu schreiben ist.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück

 

 


Copyright © Rheinwerk Verlag GmbH 2017

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de