getAgentOutput vs. OutputStream

[jBubbleBoy]

Hallo Forum,
ich möchte mit Domino R6 über einen JavaAgent (Web) einen OutputStream erzeugen, der JavaAgent bietet mir aber nur einen PrintWriter an:
getAgentOutput
den getAgentOutputStream gibt es ja erst ab Domino R7.
Meine Frage: habe ich etwas übersehen, kann man das anders lösen oder habe ich einfach keine Chance einen OutputStream zu erzeugen?

bubble

[jBubbleBoy]

da gibt es wohl keine andere Möglichkeit, außer man geht einen (kleinen) Umweg:
http://dev.kanngard.net/Permalinks/ID_20021101011753.html


bubble

[flaite]

Wofür brauchst du das?
Willst du einen binärstream erzeugen?

PrintWriter besitzt ein out member (s. JavaDoc PrintWriter.out).
Das kannst du dann in einen Binärstream umwandeln.
Falls du einen characterstream an den Client senden willst, ist PrintWriter völlig i.O.

[jBubbleBoy]

Ämmm, also ich möchte mit iText PDF generieren und diesen als Stream an den Browser senden. Der NotesAgent gibt mir einen PrintWriter, iText benötigt einen OutputStream. Wie z.B.:

Code

PdfWriter.getInstance(document, new FileOutputStream(fout));

Da würde ich jetzt denken das ich den PrintWriter zum OutputStream umwandeln müsstem, was nicht geht oder?

bubble

[animate]

Eine Suche in google nach javaagent outpustream gab mir diesen Link hier als ersten Treffer:

http://lekkimworld.com/2005/11/12/creating_a_download_tracker_for_domino.html

Offensichtlich hat der JavaAgent eine undokumentierte Methode getAgentOutputStream. Für den Autor des Artikels funktionierte die aber nicht so richtig und er empfiehlt schließlich, ein Servlet an Stelle des Agents zu nehmen

[flaite]

gäb aber wenn mich nicht alles täuscht noch die Möglichkeit den character input Stream in einen byte output stream zu konvertieren. Das hat Mikkel Heisterberg (Autor des guten Artikels) nicht gemacht. Hab zu tun, poste aber wenn ich weiss wie.

[flaite]

Hm. So einfach ist das doch nicht. Du willst praktisch als in IBatis verwendeten Stream direkt PrintWriter verwenden. Ich würd dann doch eher zu einer Servlet Lösung tendieren. Kannst ja auch die antike Domino Servlet Implementierung benutzen. Ist nur ein gewisser administrativer Aufwand. Aber kein großer.

[jBubbleBoy]

hab jetzt erstmal 'ne Demo mit Dokument + Attachment + redirekt gebastelt, produktiv wird's wohl ein Servlet werden.

bubble

[flaite]

Vielleicht ist das mit Document + Attachment sogar besser.
Dann kannst du nämlich die Ergebnisse cachen.
Mit IBatis on the fly ein pdf zu erzeugen ist ziemlich kostspielig.
Cachen macht natürlich nur Sinn, wenn sich die Dokumente nicht mehr so oft oder viel besser gar nicht mehr ändern.

Cachen wäre:
Guck erst mal, ob es für das angeforderte Dokument bereits ein Attachment gibt.
Wenn ja, liefer das aus und du brauchst keine IBatis Operationen mehr.
Wenn nein, führ die Ibatis Operation durch, speicher das Attachment (damit es beim nächsten mal da ist) und liefer es aus.
Wenn sich die Dokumente natürlich so ändern, dass sich auch das ausgelieferte PDF ändert, müsstest du das beim querySave des Dokumentes prüfen und das Attachment löschen.
Oder du führst die iBatis Operationen sowieso im Querysave aus. Damit würde aber das Speichern länger dauern.
Meist wird aber auf Daten viel öfter lesend als schreibend zugegriffen, so dass dies ok wäre.

[jBubbleBoy]

@Axel: Mit ibatis will ich doch gar nüscht machen, das ist doch ein Persistenzframework, kann man damit PDF's erzeugen? Ich wollte dafür iText benutzen.
Cachen ist aber eine schlechte Idee, da die Ausgangsbasis wohl Ansichten in XML Format sein wird, aber das muss ich nochmal eruieren. 
Aber ich hab mal noch eine ganz andere Frage. Du kennst Dich doch gut mit Struts, Spring und JSF aus. Ich soll demnächst einen personalisierten Webauftritt mit J2EE planen und umsetzen und mir stellt sich die Frage, welches Framework ich dafür einsetze soll? Was sind die großen Unterschiede?

bubble

[flaite]

Ich hab das verwechselt. Meinte iText statt iBatis. 

Ich schul hier gerade wöchentlich Enterprise Java mit einem Schwerpunkt auf Spring.
Die Unterschiede sind ziemlich vielfältig aber konzeptionell nicht so groß.
Bei der Schulung hab ich gemerkt, dass das eigentlich ziemlich viel Stoff ist.
Welchen Application Server benutzt du?
Sollte dies mehr ein Einzelkämpfer-Projekt sein, rate ich von Websphere ab.
Mit Spring reicht Tomcat aus. Die Alternative wäre JBoss oder Glassfish von Sun.
Eine große Hilfe sind Bücher, die den ganzen "Framework-Stack" beschreiben. Etwa die beiden relativ kurzen aber guten deutschen Bücher "Spring und Hibernate: Eine praxisbezogene Einführung" und "Java Server Faces: Ein Arbeitsbuch für die Praxis". Leider beschreiben die nicht mehr die aktuellsten Versionen der Frameworks. Da gibts halt ständig Verbesserungen. Ist aber nach wie vor ok. Beide behandeln den Stack "Hibernate, Spring, JSF". Sehr gut ist auch "Spring in Action 2".
In Foren und Blogs (www.javablogs.com) gibt es eine Menge Informationen zu dieser Art der Programmierung. Man findet auch mit google leichter Sachen als mit Notes-Programmierung und man kann Sachen abkupfern. Gerade für Anfänger kann Hibernate relativ schwer sein.
Ich präferiere heute möglichst einfache Infrastruktur. Also eher Tomcat. Ausser für wirklich große, geschäftskritische, unternehmensweite Entwicklungsprojekte, an denen vielleicht 10 bis 20 Leute maßgeblich beteiligt sind und das von der Geschäftsführung nachdrücklich strategisch unterstützt wird, hat man damit eigentlich nur Vorteile.   
Wenn du Websphere benutzen mußt, mach AUF KEINEN FALL EJB. Websphere unterstützt ausser als Zusatz nur EJB2 und das hat unter Entwicklern viel Wut, Entsetzen, Ablehnung und Widerstand erzeugt. EJB3 ist ok, gibts aber nur als Zusatz.
Eine Alternative wäre EJB3 gegebenenfalls mit SEAM, aber da kenn ich mich zur Zeit nicht so gut mit der Literaturlage aus. Es gibt sie aber. Wie gesagt: Es ist eine GEWALTIGE oder besser UNVERZICHTBARE Hilfe von einem Buch auszugehen, das eine GESAMTE Anwendung erklärt, das auch das Zusammenspiel der einzelnen Komponenten, ein gewisses Architekturverständnis und einen Projekt-Prozess (Stichwort Unit-Tests!) vermittelt.
In Verhältnis zu Notes-Programmierung halte ich das Literatur-Ding nicht als ein Anzeichen von "Über-Komplexität". Zumindest nicht aus meiner Praxis. Sie helfen wirklich in einem praxis-tauglichen Einsatz für diese Werkzeuge. Wenn man in Notes "neue" (also 6 Jahre) alte Apis benutze wie die "neuen" RichText Klassen oder DXL sind dort so viele Dinge quasi undokumentiert und man muss das irgendwie kostspielig selber herausfinden.

viel glück

Axel

[jBubbleBoy]

jo erstmal danke für den input.
Ich muss mich wohl einfach für ein Framework entscheiden und das wird wohl Spring sein.
Ich hab bisher immer mit Tomcat "rumgemacht", zum Einsatz kommt aber wohl JBoss. Aber das ist ja eh nur der Container und damit sekundär. Websphere wird es definitiv nicht sein.

bubble

[flaite]

Für JBoss ist das hier eine sehr bedenkenswerte Alternative:
http://www.manning.com/dallen/

Hinter Seam steht der Hibernate Entwickler Gavin King, der bei JBoss arbeitet.
Das ist auch gut.

Nach meinem Verständnis entwickelt sich JBoss parallel zu Spring. Die Grundkonzepte sind aber sehr ähnlich, um nicht zu sagen gleich für den Anwendungsentwickler.
Interceptoren/AOP, Inversion of Control.
Das Buch gibts bisher nur als Beta PDF. Hör nur gutes drüber.