Problem mit Domino DXL export

[qojote]

Hi,

folgendes Problem ich exportiere ein Notes Document mit der DXLexporter Klasse und versuche aus dem Stream im Speicher ein XML Document zu erzeugen mit einem SAXBuilder.
Jetzt zum Problem im DXL output gibt es leider kein charset.
Hat jemand eine Ahnung wie ich das setzen kann ich habe jetzt die Doku und alle Foren durch habe aber keine Möglichkeit gefunden.
Ich benutze im Moment Version 6.51
Ich habe das ganze nochmal in Lotusscript gemacht und das Dokument erst in ein File exportiert da ist alles da ( Charset UTF-8 ) so wie ich das auch erwartet hätte.
Vielleicht ein Bug in den Java Klassen ?

Vielleicht hat ja jemand eine Idee.

Gruß
qojote

[flaite]

Hi,

wieso charset?
Alle xml Dokumente haben zumindest implizit ein encoding (z.B. UTF-8).
Dies steht in dem <?xml version="1.0"?> tag. Dieses Angabe ist allerdings optional.
Z.B: <?xml version="1.0" encoding="ISO-8859-1"?>
Jede Datei ist im Computer erstmal binär. Das implizite oder explizite encoding regelt für welche characters die einzelnen bytes stehen. 
Ich hab in letzter Zeit wenig DXL gemacht. Da gibts aber sicher keinen bug.
Vielleicht kannst du den entsprechenden Code  hier mal posten.

Gruß Axel 

[flaite]

Hier ist vereinfachter Beispielcode, den ich gestern geschrieben (läuft in Domino7 Java-Agenten).
SpiSaxParsingException extends java.lang.Exception
CustomSAXHandler extends org.xml.sax.helpers.DefaultHandler

Code

public class SaxManager {

	private SAXParserFactory factory = SAXParserFactory.newInstance();

	public SaxManager() {

	}

	public void doParse(InputStream is)
			throws SpiSaxParsingException {
		try {
			SAXParser saxParser = factory.newSAXParser();

			DefaultHandler handler = new CustomSAXHandler();
			saxParser.parse(is, handler);

		} catch (Exception e) {

			throw new SpiSaxParsingException(e);

		}

	}

}

Eine Methode in CustomSAXHandler wäre z.B.:

Code

	public void startElement(String uri, String localName, String qName, Attributes attributes) {
		Map attrs = new HashMap();
		for (int i=0;i<attributes.getLength();i++) {
			attrs.put(attributes.getQName(i), attributes.getValue(i));
		}
		
		System.out.println("Event Type: Start Element");
		System.out.println("Element Name:"  + qName);
		System.out.println("attributes=" + attrs);
		
	}

[qojote]

Hi,

vielen Dank für den response.
Tut mir leid das ich erst so spät poste aber ich war den ganzen Tag unterwegs.

Das war die Fehlermeldung.
org.jdom.input.JDOMParseException: Error on line 1: "Malformed UTF-8 char -- is an XML encoding declaration missing?"
Ich meinte die würde produziert weil bei dem DXL export kein encoding in das File geschrieben wird.

Hier der Code: (gekürzt auf das wichtigste )
Die Exception tritt an der Stelle auf an der der InputStream an den Saxbuilder übergeben wird.

DxlExporter dxl=s.createDxlExporter();
dxl.setOutputDOCTYPE(false);

String outstring=dxl.exportDxl(doc);

InputStream bais = new ByteArrayInputStream( outstring.getBytes() );
SAXBuilder builder = new SAXBuilder();
jdoc = builder.build(bais);

Ich habe jetzt statt den InputStream einen StringReader benutzt und da tritt der Fehler nicht auf.
Jetzt habe ich zwar mein Problem gelöst, verstehe aber leider nicht wieso das so ist.
Vieleicht hast du ja eine erklärung. Wäre ich echt dankbar für.
Gruß
Qojote

[flaite]

Hi,

mit Streams ist es immer ein bischen frickelig. Macht Sinn sich da die Kapitel über Streams/Readers  durchzulesen. Im Handbuch der Javaprogrammierung (www.javabuch.de) wären das Kapitel 18 und 19. Les einfach solange, bis es zu langweilig sind. Die wichtigsten Sachen stehen oben. Ich muß das öfters mal nachlesen, obwohl ich schon viel mit Streams/Readers gemacht habe.

Java kennt bzgl. Streams 2 unterschiedliche Typen.
Byte orientiert Streams und character orientierte Streams. Die Namen der letzteren enden meist mit Reader oder Writer. 
Byte orientierte Streams lesen/schreiben 1 byte je read().
Character orientierte Steams lesen/schreiben 1 character je read().
Character orientierte Streams haben immer ein encoding. Physisch liegen ja die Daten immer als Bytes vor. Characters sind eine Abstraktion, die ein Encoding Schema zwingend erfordert. Erst dann weiss der Character-orientierte Stream auf welche Characters sich die physischen Bytes mappen.
Offenbar benutzt build(InputStream) von org.jdom.input.SAXBuilder das in <?xml?> stehende encoding. Wenn nix da ist, scheint er UTF-8 zu benutzten (Fehlermeldung: Malformed UTF-8 char). Das verstehe ich nicht. Vorallem weil das mit dem ByteArrayInputStream da nicht reinläuft. Er benutzt dann die Methode build (Reader von org.jdom.input.SAXBuilder (eine überladene Methode). 

Aber jetzt etwas völlig anderes: Man sollte das nicht in einem String zwischenspeichern.
Streams sind gerichtete Ströme von Bytes, die von einer Quelle lesen und in ein Ziel schreiben.
Der DxlExporter erzeugt einen Stream. Du richtest diesen Stream in einen String. Diesen String benutzt du als Quelle für einen neuen Stream, der vom JDOM Parser als input  verwendet wird. Das Erzeugen dieses 2ten Streams beansprucht viele Ressourcen (inperformant). Ich seh aber z.Zt auch keine Möglichkeit aus DxlExporter direkt einen Stream zu bekommen (Skandal).
In der Hilfe benutzen die

Code

stream.writeText(exporter.exportDxl(nc))

Nicht gut, dass das zwischendurch in einem String geschrieben wird. Ausserdem funktioniert das nicht bei sehr großen Dokumenten, weil der gesamte String auf einmal in den Speicher geladen wird. Mit Streams geht das nämlich häpchenweise.

Streams müssen immer geschlossen werden!!! Nach jdoc.builder.build(bais) IN JEDEM FALL ein bais.close();
Oder eigentlich ca. so:

Code

ByteArrayInputStream bais = null;
try {
DxlExporter dxl=s.createDxlExporter();
dxl.setOutputDOCTYPE(false);

String outstring=dxl.exportDxl(doc);

InputStream bais = new ByteArrayInputStream( outstring.getBytes() );
SAXBuilder builder = new SAXBuilder();
jdoc = builder.build(bais);
} catch (Exception e) {
e.printStckTrace(); 
} finally {
if (bais != null) {
 try {
   bais.close();
  } catch(Exception e) {}
}

Werd die offnenen Fragen noch mal genauer prüfen.


Gruß Axel

[qojote]

Hi,

vielen Dank für deine Antwort.

Werde mir die entsprechenden Kapitel durchlesen.

Gruß
Qojote

[flaite]

Nur zu empfehlen.
Sehr viele Sachen, für die ich Java in Notes einsetze, haben mit io-Streams zu tun.
(zip Files, Webservices und das neueste ist jetzt Archivierung von Zuständen auf einer Intranet Seite mit HTML Parsern, die auch mit potentiell wirklich chaotischem html klarkommen).
NIO ist a) kompliziert und b) aus meiner Erfahrung für sehr viele Anwendungen nicht nötig.