JDOM spørgsmål

Original: http://www.jdom.org/docs/faq.html

Hvad er JDOM?
Hvad er JDOM ikke?
Er JDOM et akronym?
Hvad er JDOM licens?
Hvor kan jeg få JDOM?
Hvilken Maven artefakt skal jeg bruge?
Hvad er JDOM filosofi?
Hvorfor er JDOM API er defineret i form af konkrete klasser snarere end grænseflader?
Hvordan JDOM arbejde med DOM og SAX?
Blev JDOM designet til Generics?
Jeg forsøgte at bruge JDOM og få en fejl som denne: java.lang.NoSuchMethodError eller java.lang.NoClassDefFoundError: org / xml / sax / SAXNotRecognizedException
Hvad mener du med „Standard udvidelse mappe“?
Hvordan undgår jeg det DOM Level 1 problem i Visual Age for Java?
Hvordan undgår jeg det DOM Level 1 problem i WebSphere?
Hvad JDOM version fungerer som JDK?
Er der nogen ydeevne tal?
Hvordan JDOM integrere med XSLT?
Er der XPath støtte JDOM?
Hvilke funktioner af XML ikke er fuldt håndteres af JDOM?
Er JDOM gevind sikkert?
Hvorfor ligemænd () kun gøre en == check?
Hvorfor er ligemænd () er erklæret endelig?
Hvordan kan jeg konstruere et dokument fra en streng?
Hvordan fjerner jeg et element eller andet indhold?
Hvordan flytter jeg et Element fra et sted til et andet?
Hvordan kan jeg kopiere et Element fra et sted til et andet?
Kan et element eller attribut navn indeholde et kolon?
Hvorfor skal jeg nødt til at passere i et navneområde til getChild (), når barnet element jeg leder efter har nogen erklæring namespace?
Hvis jeg udelader namespace fra den anden indkaldelse til getChild (), returnerer null. Hvorfor?
Hvorfor alle nye linjer vises som \ n, selv på Windows?
Hvorfor setText („“) ikke gøre, hvad jeg vil?
Når du bruger en IDE debugger Hvorfor ser jeg en mærkelig ArrayIndexOutOfBoundsException?
Hvordan tilføjer jeg en PI eller kommentar før rodelementet?
Hvordan undgår jeg at få en OutOfMemoryError?
Hvorfor min filkodningen på udgang ikke matcher kodning på input?
Hvorfor passerer et dokument via en stikdåse til tider hænge parser?
Hvordan holder jeg DTD fra læsning? Selv når jeg slukker validering fortolkeren forsøger at indlæse DTD-filen.
Hvordan validerer jeg imod et skema, når du bruger JDOM 2.x?
Hvordan validerer jeg imod et skema, når du bruger JDOM 1.x?
Hvordan kan jeg udføre i-hukommelse validering mod en DTD eller Schema?
JDOM sikrer dokumentet i hukommelsen altid velformede. Kan JDOM også sikre dokumentet i hukommelsen er altid gyldig?
Hvorfor får jeg en IndexOutOfBoundsException eller ConcurrentModificationException på looping?
Er der et arkiv for JDOM postlister?
Hvordan afmelder jeg en adresseliste?
Hvordan sender jeg til postlisten fra flere adresser?
Skal jeg spørge generelle XML spørgsmål til Jason, Brett, eller Rolf?
Bogen Java og XML taler om JDOM 1.0; hvorfor forvirring?
Jeg har et spørgsmål som ikke er besvaret her. Hvad skal jeg gøre?
Hvordan indsender jeg en fejlrapport?
Hvor kan jeg lære mere?
Hvad er JDOM?

JDOM er ganske enkelt en Java-repræsentation af et XML-dokument. JDOM giver en måde at repræsentere dette dokument til nem og effektiv læsning, manipulation og skrivning. Det har en enkel API er en let og hurtig, og er optimeret til Java programmør. Det er et alternativ til DOM og SAX, selvom det integrerer godt med både DOM og SAX.

Hvad er JDOM ikke?

JDOM er ikke en wrapper for W3C DOM, eller en anden version af DOM. JDOM er en Java-baserede „dokument objekt model“ for XML-filer. JDOM tjener det samme formål som DOM, men er nemmere at bruge.

JDOM er ikke en XML-parser, ligesom Xerces eller Crimson. Det er et dokument objekt model, der bruger XML-parsere at bygge dokumenter. JDOM s SAXBuilder klasse for eksempel bruger sax begivenheder genereret af en XML-parser til at bygge en JDOM træ. Som standard XML-parser, der anvendes af JDOM er JAXP valgte parser, men JDOM kan bruge næsten enhver parser.

Er JDOM et akronym?

Nope. Ligesom JDBC er ikke officielt en forkortelse, er hverken JDOM. Dette sikrer, at vi overholder politikkerne Suns varemærke som forklaret på http://www.sun.com/policies/trademarks.

Hvad er JDOM licens?

JDOM er tilgængelig under en Apache-stil open source licens, med erkendelsen klausul fjernet. Denne licens er blandt de mindst restriktiv licens til rådighed, gør det muligt for udviklere at bruge JDOM skabe nye produkter uden at kræve dem til at frigive deres egne produkter som open source. Dette er den licens model, der anvendes af Apache-projektet, der har skabt det Apache-server. Licensen er tilgængelig i toppen af ​​hver kildefil og i LICENSE.txt i roden af distributionen.

Hvor kan jeg få JDOM?

JDOM er tilgængelig i binær og kilde form fra http://www.jdom.org.

JDOM fås også i maven centralt i gruppen ‚org.jdom «med artefakt id JDOM for JDOM 1.x (og visse tidligere 2.x versioner): JDOM 1.x artefakter på maven, eller med artefakt id jdom2 for JDOM 2.x: JDOM 2.x artefakter på maven

Den fulde kildekode repository fastholdes på GitHub.

Hvilken Maven artefakt skal jeg bruge?

Alle JDOM versioner er tilgængelige i „JDOM« eller »jdom2 ‚artefakt i org.jdom gruppe på Maven. Maven artefakter er et rod med tidlige JDOM 2.x versioner optræder i »JDOM ‚artefakt, og senere 2.x versioner i“ jdom2‘ artefakt. Maven ikke tillader fastsættelse af fejltagelser, wil så Maven brugere bare nødt til at leve med det som det er.

Hvis dit projekt er en, der kræver både JDOM 1.x og 2.x, så kan du også bruge ‚JDOM-legacy‘ artefakt til at trække i version 1.1.3 (eller senere 1.x udgave).

Hvad er JDOM filosofi?

JDOM har været og vil fortsat blive udviklet med denne filosofi:

JDOM bør være ligetil for Java-programmører.
JDOM bør støtte nem og effektiv dokument modifikation.
JDOM bør skjule kompleksiteten i XML hvor det er muligt, mens de resterende tro mod XML-specifikationen.
JDOM bør integrere med DOM og SAX.
JDOM skal være let og hurtig.
JDOM skulle løse 80% (eller flere) af Java / XML problemer med 20% (eller mindre) af indsatsen
Hvorfor er JDOM API er defineret i form af konkrete klasser snarere end grænseflader?

Dette spørgsmål er blevet drøftet flere gange på JDOM postliste, med flere mennesker på begge sider. I almindelighed, mange mennesker føler, at et klassebaseret API er bedre, når subclassing ikke er nødvendig, mens en grænseflade-baserede API er bedre, når subclassing er nødvendig. Imidlertid kan begge systemer anvendes i begge tilfælde.

Jason Hunter opsummerer argumenterne imod et interface baseret API til JDOM:

Med interfaces alt bliver en fabrik, elementer skal „importeret“ til nye dokumenter i stedet for bare tilføjet, funktioner som langsigtet serialisering kan ikke garanteres, og listen fortsætter.

Vi startede med grænseflader faktisk. Under vores pre-release gennemgang til nogle peers, vi modtog feedback bør vi forsøge konkrete klasser. Vi gjorde, og designet var meget bedre for det.

Tænk java.io.File som en analogi. Der er en grund vi siger:

Fil forælder = ny fil (filepath);
Fil barn = ny fil (forælder, „aaa.txt“);
snarere end

FileSystem fs = FileSystem.getDefaultFileSystem ();
Fil forælder = fs.getFile (filepath);
Fil barn = fs.getFile (forælder, „aaa.txt“);
Førstnævnte er simpelthen lettere og pænere at håndtere.

Et andet punkt at huske på er, at alt, der kan gøres med grænseflader kan gøres med underklasser – den eneste straf er muligvis ubrugte variabler i basisklassen.

For reference, den nyeste postliste diskussion om dette emne startede 30 november, 2000 med „grænseflader“ og fortsatte med „Grænseflade-baserede JDOM“ og „Annoncer: JDOMPlus“. Det ville hjælpe, der anmelder denne diskussion før at bringe dette emne op på postlisten.

Hvordan JDOM arbejde med DOM og SAX?

JDOM dokumenter kan bygges fra XML-filer, Dom træer, SAX begivenheder, eller en anden kilde. JDOM dokumenter kan konverteres til XML-filer, Dom træer, SAX begivenheder, eller en anden destination. Denne evne viser sig nyttigt, for eksempel når integrere med et program, der forventer SAX begivenheder. JDOM kan parse en XML-fil, lad programmøren nemt og effektivt manipulere dokumentet, så brand SAX begivenheder til det andet program direkte – ingen konvertering til en føljeton format er nødvendig.

Blev JDOM designet til Generics?

JDOM var designet før Generics, men JDOM 2.x har taget den gennemprøvede design JDOM 1.x og udvidet den til at bruge Generics hvor det er muligt. Specifikt alle samlinger-baserede operationer kræver passende maskinskrevne input, og returnere passende indtastede resultater. Endvidere JDOM 2.x drager fordel af andre Java 5 funktioner som varargs, og co-variant returtyper.

Generics: Element.getAttributes () returnerer List , Element.getChildren () returnerer List osv

Co-variant returtyper: Element.clone () returnerer Element, Text.detach () returnerer tekst osv

Jeg forsøgte at bruge JDOM og få en fejl som denne:

java.lang.NoSuchMethodError
eller
java.lang.NoClassDefFoundError: org / xml / sax / SAXNotRecognizedException
Hvad er der galt?

Du er nødt til at sikre, at xerces.jar fil leveres med JDOM download er i din classpath før alle andre XML-klasser, såsom dem, der kommer med JAXP eller Crimson. Disse andre XML-biblioteker, samt ældre versioner af Apache Xerces støtter DOM Level 1 og SAX 1.0, ikke den krævede DOM Level 2 og SAX 2.0. Resultatet er en undtagelse kastes. Tjek din classpath, og prøv igen. Hvis classpath ser OK, måske den problematiske JAR også gemmer sig i systemets standard udvidelsens mappe (se nedenstående).

Hvad mener du med „Standard udvidelse mappe“?

Standarden udvidelsens mappe er en mappe, der indeholder JAR-filer, der er søgt automatisk af Java Runtime og compiler. Hvis du har installeret JDK (ikke bare den JRE) kan du godt have to separate ext mapper, hvoraf den ene anvendes til at samle (typisk et sted som C: \ jdk1.3 \ jre \ lib \ ext) og den anden af som bruges til at køre kode (typisk et sted som C: \ Program Files \ JavaSoft \ JRE \ 1.3 \ lib \ ext). Den forkerte JAR-filen i enten biblioteket kan komme i din måde (selvom på forskellige tidspunkter). Endvidere den rigtige JAR-filen skal være i begge mapper.

Hvordan undgår jeg det DOM Level 1 problem i Visual Age for Java?

Når WTE-funktionen føjes til arbejdsområdet, er projektet »IBM XML Parser til Java“ tilføjede så godt. Dette projekt indeholder gamle DOM Level 1 ‚org.w3c. *‘ Grænseflader. JDOM afhængig DOM Level 2, og derfor conficts med dette projekt. Løsningen er at gøre følgende:

Skift arbejdsområde ejer til administrator
Opret åben udgave af projektet »IBM XML Parser til Java ‚
Slet alle de pakker, der indeholder org.w3c. * Grænseflader
Version projektet.
Opret et nyt projekt for DOM Level 2 parser såsom Xerces
Importere alle Xerces klasser, herunder org.w3c. * Interfaces (du kan bruge en fuldstændig forskellige projekt for disse grænseflader, hvis du ønsker at arbejde med andre parsere)
Version Xerces projekt
Opret et JDOM projekt og importere JDOM klasser ind i det. Version projektet
(Bidraget med Guy Nirpaz)

Hvordan undgår jeg det DOM Level 1 problem i WebSphere?

WebSphere har det samme problem med DOM Level 1 grænseflader som VAJ ovenfor. Løsningen er at gøre et af følgende:

Sæt stien til xerces.jar (eller andre DOM Level 2 interfaces) i variablen com.ibm.ejs.sm.adminserver.classpath «i filen admin.config. Det er bosat i $ WAS_ROOT $ / bin før alle andre variable.
eller, hvis du kører var $ WAS_ROOT / bin / debug / adminserver. {bat | sh} tilføje en linie ’sæt WAS_CP = xerces.jar‘ (eller andre DOM Level 2 interfaces), før andre sæt WAS_CP kommandoer.
eller tilføje JDOM til applikationsserveren CLASSPATH, enten ved hjælp af admin.cfg fil eller administrationen konsollen.
(Bidraget med Guy Nirpaz)

Hvad JDOM version fungerer som JDK?

JDOM 1.x versioner understøtter JDK 1.2 og senere.

JDOM 2.x versioner understøtter JDK 1.5 og senere.

Er der nogen ydeevne tal?

Den JDOM 2.x udviklingsprocessen inkluderet benchmarks for sporing ydeevne ændringer. Der er ydeevne tal, der sammenligner forskellige versioner af JDOM 2.x samt sammenligner ydeevne JDOM på forskellige JDK versioner.

Dennis Sosnoski tidligere kørte benchmarks. I almindelighed er de fleste XML objektmodeller er i samme område.

Hvordan JDOM integrere med XSLT?

Der er mange måder at gøre XSL forvandler med JDOM. Den mest enkle måde er at bruge standard JAXP Transformer-interface og JDOMSource / JDOMResult klasser fundet i org.jdom2.transform pakken. Kig til prøven opkaldt XSLTransform for et eksempel.

Er der XPath støtte JDOM?

Ja! Det er fuldt integreret i org.jdom2.xpath som Beta 9, baseret på Jaxen.

Hvilke funktioner af XML ikke håndteres af JDOM?

Ingen som vi kender til.

Er JDOM gevind sikkert?

Kernen API er bevidst ikke tråd sikkert. Med andre ord er der ingen synkroniserede blokke inden org.jdom. Denne beslutning giver mening, fordi vi forventer, at de primære JDOM use cases til at være:

Enkelt tråd læser en XML stream i JDOM og ser på det kun læser
Enkelt tråd læser en XML stream i JDOM og ændrer det
Enkelt tråd læser en XML stream i JDOM og gør den tilgængelig for en køre tid for læseadgang
Brugen tilfælde, hvor en „Single gevind læser en XML stream i JDOM og udsætter det for flere tråde at ændre dens indhold“ er forholdsvis sjældne. I så fald kan JDOM stadig foretages tråd sikkert, men programmøren blot har at udføre deres egen synkronisering, måske som synkronisering på Document instans.

På den anden side er der visse funktioner, der kræver »operationelle« dele af JDOM at være Thread sikker:

org.jdom2.Namespace.getNamespace () er sikkert
Alle fabrik-type klasser er sikker (XPathFactory etc.)
Hvorfor ligemænd () kun gøre en == check?

I JDOM to Content objekter er kun lige, hvis de er nøjagtig samme objekt. Dette lader et opkald ligesom list.remove (elem) kun fjerne den nøjagtige Element bestået i, ikke noget element, der er ækvivalente. Dette er en meget vigtig forskel. Gør en fuld ligemænd () på et Element ville kræve rekursiv ned i træet, og generelt mener vi det usandsynligt, du ønsker at vide, om dette element, og alle dets børn svarer til en anden. Hvis du virkelig ønsker at vide, kan du skrive nogle sammenligning kode selv, der kontrollerer kun så meget, som du vil kontrollere (måske name / kun navnerum) i stedet for at gøre en fuld recurse.

Hvorfor er ligemænd () er erklæret endelig?

Lighedstegnet () metoder er endelig for JDOM Content klasser, således at en underklasse, ikke kan bryde == adfærd, der kræves for opkald som list.remove (elem) for at virke efter hensigten. Tilsvarende hashCode () metoder er også endelig (for at bevare ligeværdige / hashCode kontrakt).

Hvordan kan jeg konstruere et dokument fra en streng?

Du bruger standard Java IO bibliotek opkald. Wrap snor med en StringReader og videregive læseren til SAXBuilder:

Dokument doc = builder.build (ny StringReader (XML));
Hvordan fjerner jeg et element eller andet indhold?

Anvende metoderne på listen returneres af getChildren () eller getContent (). JDOM behøver ikke særlige metoder, fordi de metoder, der allerede findes i Liste. For eksempel for at fjerne et element fra en liste over børn:

Liste børn = parent.getChildren ();
children.remove (element); // Givet barn
children.remove (0); // Første barn
Andre metoder på liste giver mulighed for at fjerne alle børn, tilføje et barn på et givet sted, og så videre.

Hvis du har et bestemt element eller andet indhold, som du vil fjerne fra sin forælder, kan du frigøre indholdet med Content.detach () metode.

Hvordan flytter jeg et Element fra et sted til et andet?

Der er ikke behov for node „importerende“ ligesom der er med DOM. Bare fjerne elementet fra dets nuværende sted, tilsæt derefter elementet til den nye plads. Elementets indhold (herunder sit rette element børn) vil naturligt „tag“ med på turen. Du er nødt til at fjerne det element, før du tilføjer den til den nye sted, fordi elementer kan kun have én forælder returneres af getParent ().

newParent.addContent (elt.detach ());
Hvordan kan jeg kopiere et Element fra et sted til et andet?

Der er ikke behov for node „importerende“ ligesom der er med DOM. Bare klone element bliver kopieret og tilføje sin klon i sin nye plads. Du er nødt til at klone det element, før du tilføjer den til den nye sted, fordi elementer kan kun have én forælder returneres af getParent ().

newParent.addContent (elt.clone ());
Kan et element eller attribut navn indeholde et kolon?

XML 1.0-specifikationen specifikt forbeholder kolon karakter til brug sammen med XML-namespace. Ingen anden brug er i overensstemmelse med XML 1.0. Derfor JDOM ikke tillade dig at oprette element og attribut navne, der indeholder koloner, undtagen når du bruger navnerum. På grund af den måde, navnerum er implementeret i JDOM, du kan ikke bare oprette et element eller data med en fuldt kvalificeret navn som SVG: titel. Det er du ikke kan gøre dette:

Element e = nyt element („SVG: titel“);
I stedet skal du opdele de to dele i et navneområde og et lokalt navn. Dette er den rigtige JDOM måde at skabe et element i et namespace:

Element e =
nyt element („title“, „SVG“, „http://www.w3.org/2000/svg“);
Det første argument er det lokale navn. Det andet argument er præfikset. Det tredje argument er namespace URI.

Hvis du forsøger at oprette xml: lang og xml: space attributter bruger:

Element e =
nyt element („Lang“, Namespace.XML_NAMESPACE);
Hvorfor skal jeg nødt til at passere i et navneområde til getChild (), når barnet element jeg leder efter har nogen erklæring namespace?

Specifikt for denne XML-fragment:

Du skal bruge kode som denne:

Navnerum ns = Namespace.getNamespace („http://foo.com“);
Element y = x.getChild („y“, NS);
Element z = y.getChild („z“, NS);

Hvis jeg udelader namespace fra den anden indkaldelse til getChild (), returnerer null. Hvorfor?

JDOM arbejder på det logiske i hukommelsen XML-træet, ikke den tekstuelle repræsentation på disken. Mens element Z ikke har nogen erklæring navneområde, det har en namespace – den ene arvet fra sin forælder, som erklærer en standard namespace (tilknyttet URI http://foo.com).

Ifølge navnerum specifikation følgende XML-fragment er identisk i henhold til den foregående:

Den måde at JDOM API håndterer navnerum betyder, at du kan skrive kode, der virker for begge eksempler. Ellers ville du nødt til at have kode, der kontrolleres for hver enkelt sag for sig.

Tilsvarende, hvis du var at konstruere (i stedet for læsning) XML i det første eksempel ovenfor, ville du nødt til at skrive kode som denne:

Navnerum ns = Namespace.getNamespace („http://foo.com“);
Element y = nyt element („y“, NS);
x.addContent (y);
Element z = nyt element („z“, NS);
y.addContent (z);
Hvis du forlod ud namespace fx fra constructoren for elementet Z, ville du have følgende træet i hukommelsen:

Hvorfor alle nye linjer vises som \ n, selv på Windows?

I henhold til § 2.11 i XML henstillingen, 2. udgave:

For at forenkle opgaver anvendelser skal en XML-processor normalisere linjeskift i parsede enheder til #xA enten ved at oversætte de to-tegnsekvensen #xD #xA og enhver #xD, der ikke følges af #xA til #xA på input før parsing eller ved hjælp af en anden metode, således at de overføres til applikationen tegn er de samme, som hvis det gjorde denne oversættelse.
Med andre ord, det er præcis, hvad der skulle ske.

Nogle XML-input kan undslippe \ r vognretur som & # xD; og XML-parser vil oversætte dette til en sand \ r karakter i din JDOM Tekst. Når denne tekst er produktionen igen vil det være re-undsluppet som & # xD;.

Hvorfor setText („“) ikke gøre, hvad jeg vil?

Når du passerer en streng til en metode som setText () JDOM antager det er bare, at en snor, ikke et fragment af XML. For eksempel, når du ringer:

element.setText („“)
JDOM antager du ønsker at indstille indholdet til strengen indeholder de seks tegn og # 1 6 0;. Det behøver ikke tolke det at forsøge at forstå det som XML først. Således når du udskriver teksten ved hjælp XMLOutputter vil det naturligvis undslippe den særlige og-tegn og output & amp; # 160;. Løsningen er at passere regelmæssige Unicode-tegn til setText () metode, eller hvis du har tekst data, som du ønsker at blive fortolket som XML, passerer det gennem en XML-parser før den går i JDOM. Det er, hvad SAXBuilder og DOMBuilder klasser gør.

Når du bruger en IDE debugger Hvorfor ser jeg en mærkelig ArrayIndexOutOfBoundsException?

Nogle parsere (Xerces inkluderet) bruger denne undtagelse som en del af deres standardprocedure, internt kaste og fange undtagelsen. Ingen kode uden for biblioteket menes se det. Dog er IDE debuggers ofte konfigureret til at indberette enhver tid denne undtagelse er kastet, og dermed de udsætter undtagelsen. Det kan sikkert ignoreres.

Hvordan tilføjer jeg en PI eller kommentar før rodelementet?

Du skal få adgang til dokumentet indhold som en liste. Enten få listen og tilføje indhold til hovedet, eller fastsat en liste over indholdet eksplicit.

doc.getContent () tilføje (0, pi).;
eller
doc.setContent (listOfContent);
Hvordan undgår jeg at få en OutOfMemoryError?

De fleste JVMs har en mulighed for at øge deres maksimale bunke størrelse, som er den maksimale mængde hukommelse JVM kan bruge til sine objekter. Du kan indstille din oprindelige bunke størrelse til 32 Megs og maksimal bunke størrelse til 64 Megs med følgende kommando:

java -Xms32m -Xmx64m SomeClass
Hvis du ikke kræver alt dokumentet i hukommelsen, se på JDOM-contrib modulets org.jdom.contrib.input.scanner pakke, som lader dig opbygge den del af et dokument, der matcher et XPath udtryk.

Hvorfor min filkodningen på udgang ikke matcher kodning på input?

Som standard tegnsæt, der anvendes af XMLOutputter er UTF-8, en variabel længde kodning, der kan repræsentere alle Unicode-tegn. Dette kan ændres med en opfordring til format.setEncoding () på Formater objekt videre til XMLOutputter. Det ville være rart, hvis XMLOutputter kunne starte op på den oprindelige kodning for en fil, men desværre parsere viser ikke den oprindelige kodning. Du er nødt til at indstille det programmeringsmæssigt.

Dette problem rammer oftest folk med dokumenter i den fælles ISO-8859-1 (Latin-1)-kodning, der bruger karakterer som ñ men ikke er bekendt med at skulle tænke på kodninger. Det tip til at huske er, at med disse dokumenter, skal du indstille output kodning til ISO 8859-1, ellers tegn i intervallet 128-255 vil være output ved hjælp af en dobbelt bytekodning i UTF-8 i stedet for den normale enkelt byte kodning af ISO-8859-1.

Hvorfor passerer et dokument via en stikdåse til tider hænge parser?

Problemet er, at flere XML-parsere lukke input stream, når de læser EOF (-1). Dette gælder for Xerces, som er JDOM standard parser. Det er også rigtigt af Crimson. Desværre lukker en SocketInputStream lukker underliggende SocketImpl, indstilling file descriptor til null. Stikket output strøm er ubrugelig efter dette, så din ansøgning vil være i stand til at sende et svar. For at omgå, beskytte dit socket input stream med en InputStream omslag, der ikke lukker den underliggende strøm (tilsidesætte tæt () metode), eller læse det hele i en buffer før aflevering ud til JDOM bygherre:

byte [] buf = ny byte [længde];
ny DataInputStream (InputStream) .readFully (BUF);
InputStream i = ny ByteArrayInputStream (BUF);
(Bidraget af Joseph Bowbeer)
Hvordan holder jeg DTD fra læsning? Selv når jeg slukker validering fortolkeren forsøger at indlæse DTD-filen.

Selv når valideringen er slukket, vil en XML-parser som standard indlæse eksterne DTD-filen for at parse DTD til ekstern entitet erklæringer. Xerces har en funktion til at slå denne opførsel navnet „http://apache.org/xml/features/nonvalidating/load-ekstern-dtd“, og hvis du ved, at du bruger Xerces kan du indstille denne funktion på bygherre.

builder.setFeature (
„http://apache.org/xml/features/nonvalidating/load-ekstern-dtd“ falsk);
Hvis du bruger en anden parser som purpur, din bedste chance er at oprette en EntityResolver det løser DTD uden faktisk at læse separat fil.

importere org.xml.sax *.;
import java.io. *;
public class NoOpEntityResolver implementerer EntityResolver {
offentlig InputSource resolveEntity (String PublicID, String SystemID) {
returnere ny InputSource (ny StringBufferInputStream („“));
}
}
Derefter i bygherre …
builder.setEntityResolver (ny NoOpEntityResolver ());
Der er en ulempe ved denne fremgangsmåde. Eventuelle enheder i dokumentet vil blive løst til den tomme streng, og vil effektivt forsvinde. Hvis dit dokument har enheder, skal du setExpandEntities (falsk) kode og sikre EntityResolver kun undertrykker DocType.

Hvordan validerer jeg imod et skema, når du bruger JDOM 2.x?

JDOM 2.x indfører en forenklet model til validering dokument. Den org.jdom2.input.sax.XMLReaders Enum indeholder medlemmer, der opretter din validering for dig.

Den komplette kode i JDOM 2.x ser sådan ud:

SAXBuilder builder =
ny SAXBuilder (XMLReaders.XSDVALIDATING);
Dokument doc = builder.build (XML);

Hvordan validerer jeg imod et skema, når du bruger JDOM 1.x?

JDOM 1.x har ikke sin egen fortolker, det bruger standard parsere som Xerces at gøre det tunge løft. Hvis du vil have skemavalideringen sørg for at vælge en parser der understøtter skemaer. Xerces 2 er et godt valg (få det fra http://xml.apache.org). Du skal også bruge koden JDOM Beta 8 eller senere.

Til at specificere parser JDOM bruger, kan du enten konfigurere JAXP passende (siden JDOM bruger JAXP hvis den er tilgængelig, se enden på denne post for detaljer), eller kan du eksplicit passere navnet parseren til SAXBuilder konstruktør. For Xerces 2 parseren klasse er org.apache.xerces.parsers.SAXParser. Du skal også aktivere parser validering ved at føre „true“, når du opretter en SAXBuilder.

SAXBuilder builder =
ny SAXBuilder („org.apache.xerces.parsers.SAXParser“, true);

Næste, du fortæller parseren (Xerces), du ønsker at validere mod et skema (eller skemaer), og du passerer parseren oplysninger om dem skema. Forskellige parsere gøre dette på forskellige måder. I Xerces du gør dette ved at sætte særlige ‚Features‘ og ‚Egenskaber‘ for fortolkeren. JDOM udsætter disse parser indstillinger med setFeature () og setProperty () metoder på SAXBuilder. Disse pass-through metoder blev tilsat efter Beta 7, hvilket er hvorfor du har brug Beta 8 eller derover.

Skemaer er aktiveret ved at indstille funktionen „http://apache.org/xml/features/validation/schema“ til sandt.

builder.setFeature (
„http://apache.org/xml/features/validation/schema“, true);

Schema steder er givet ved at indstille egenskaben „http://apache.org/xml/properties/schema/external-schemaLocation“ til en liste over blanke separeret navneværdipar. ‚Navn‘ er navnerummet skemaet er forbundet med, „værdi“ er placeringen af ​​skema for det navnerum. For eksempel:

builder.setProperty (
„http://apache.org/xml/properties/schema/external-schemaLocation“, „http://www.w3.org/2001/12/soap-kuvert sæbe-envelope.xsd“ + „“ + „http : //kevinj.develop.com/weblog/weblog.xsd weblog.xsd „);

Ovenstående eksempel viser, hvordan man validere mod flere skemaer – imod SOAP 1.2 skema, hvor navnerummet er http://www.w3.org/2001/12/soap-kuvert og og imod et skema for navnerum http: // kevinj.develop.com/weblog/weblog.xsd. Filerne, der beskriver disse skemaer er i sæbe-envelope.xsd og weblog.xsd hhv. Du kan tilføje så mange af disse navn værdipar som nødvendigt. De værdier, selv er webadresser. Navnet værdipar følge den betydning i Schema anbefalingen (http://www.w3.org/TR/xmlschema-1/#schema-LOC).

Den komplette kode ser sådan ud:

SAXBuilder builder =
ny SAXBuilder („org.apache.xerces.parsers.SAXParser“, true);
builder.setFeature (
„http://apache.org/xml/features/validation/schema“, true);
builder.setProperty (
„http://apache.org/xml/properties/schema/external-schemaLocation“
„http://www.w3.org/2001/12/soap-kuvert sæbe-envelope.xsd“ + „“ +
„http://kevinj.develop.com/weblog/weblog.xsd weblog.xsd“);
Dokument doc = builder.build (XML);

Hvis du ønsker at bruge JAXP at vælge parser, kan du springe angive en klasse til SAXBuilder konstruktøren og i stedet indstille systemet egenskab „javax.xml.parsers.SAXParserFactory“ til værdien „org.apache.xerces.jaxp.SAXParserFactoryImpl“ . Det fortæller JAXP at bruge Xerces ‚fabrik til at bygge parsere. Hvis du vil, kan du angive denne egenskab på kommandolinjen:

java -Djavax.xml.parsers.SAXParserFactory =
org.apache.xerces.jaxp.SAXParserFactoryImpl …

(Bidraget af Kevin Jones)

Hvordan kan jeg udføre i-hukommelse validering mod en DTD eller Schema?

I øjeblikket kan du ikke gøre dette, i JDOM eller ethvert andet Java-dokument objekt model API. Men det er noget, vi gerne vil JDOM at støtte, og vi har en frivillig, der arbejder på det.

JDOM sikrer dokumentet i hukommelsen altid velformede. Kan JDOM også sikre dokumentet i hukommelsen er altid gyldig?

Nej, det er vores nuværende overbevisning, at det er bedre at udsætte en checkValid () type opkald, end at forsøge konstant validering kontrol. En årsag er ydeevne. En anden grund er, at du har en hønen-og-ægget problem, hvor for eksempel et element behov præcist to underordnede elementer at være gyldig, men efter tilsætning enten barn dokumentet vil være i en midlertidigt ugyldig tilstand. Du kan omgå dette ville kræve noget som transaktionsbeslutning ændringer, og der er en masse overhead for en lille gevinst.

Hvorfor får jeg en IndexOutOfBoundsException eller ConcurrentModificationException på looping?

Kode som følgende vil kaste et IndexOutOfBoundsException:

Liste børn = root.getChildren („foo“);
int størrelse = children.size ();
for (int i = 0; i <størrelse, jeg ++) {
Element barn = (Element) children.get (I);
child.detach ();
otherRoot.addContent (barnet);
}
Årsagen er, at størrelsen af listen er forudberegnet men størrelsen er reduceret med en på hver afbrydelse () opkald, der forårsager for-løkken til at gå væk fra enden af ​​listen. Den rigtige måde at sløjfe er at bruge en Iterator. Med en Iterator du ikke har dette problem, og det er hurtigere.

Men selv med en Iterator, følgende kode kaster en ConcurrentModificationException:

Liste børn = root.getChildren („foo“);
Iterator ITR = children.iterator ();
while (itr.hasNext ()) {
Element barn = (Element) itr.next ();
child.detach ();
otherRoot.addContent (barnet);
}
Årsagen er, at afbrydelse () kald ændrer listen over børn på samme tid iterator er gennemkører på listen, og det er en samtidig modifikation. Løsningen er at bruge Iterator os fjerne () metode i stedet for afbrydelse () i denne situation:

Liste børn = root.getChildren („foo“);
Iterator ITR = children.iterator ();
while (itr.hasNext ()) {
Element barn = (Element) itr.next ();
itr.remove ();
otherRoot.addContent (barnet);
}
Er der et arkiv for JDOM postlister?

Ja, er tilgængelige for din web-baserede gennemlæsning alle beskederne. Nedenfor er de smarte søgbare alt-i-én arkiver:

http://jdom.markmail.org
Der er yderligere arkiver på:

http://www.jdom.org/pipermail/jdom-interest/
http://www.jdom.org/pipermail/jdom-announce/
http://www.jdom.org/pipermail/jdom-commits/
Hvordan afmelder jeg en adresseliste?

Webadressen til at administrere din liste medlemmer (inklusive abonnement) er fastgjort i bunden af ​​hver liste budskab. Det bør være noget lignende http://www.jdom.org/mailman/options/jdom-interest/ [email protected] Sørg for at erstatte „youraddr“ med din adresse og „yourhost“ med din vært. For JDOM-announce erstatte „interesse“ med „annoncere“ i webadressen.

Comments are closed.