Liebe Studierende,
es hat sich unter anderem der sinnstörende Tippfehler eingeschlichen:
1. "SendMailSSL.java": müssen Sie mit dem OpenJDK-Compiler zuerst kompilieren, z.B. mit "java*x* SendMailSSL.java", anschließend rufen Sie es mit "java SendMailSSL absenderEMail passwort empfaengerEMail Betreff e-Mail-Text" auf
der Java-Compiler aus dem OpenJDK lautet "javac" und nicht "javax", daher sollte der Absatz korrekt lauten:
1. "SendMailSSL.java": müssen Sie mit dem OpenJDK-Compiler zuerst kompilieren, z.B. mit "java*c* SendMailSSL.java", anschließend rufen Sie es mit "java SendMailSSL absenderEMail passwort empfaengerEMail Betreff e-Mail-Text" auf
Die kompilierte Version von "SendMailSSL.java" wird "SendMailSSL.class" heißen. Beim Aufruf mit "java" wird aber die Dateiendung ".class" nie mit angegeben (die wird von "java" immer automatisch hinzugefügt).
Mit freundlichem Gruß
Rony G. Flatscher
On 28.01.2021 18:45, Rony G. Flatscher wrote:
Liebe Studierende,
die Gruppe 2 versucht, e-Mail über eine Java-Klassenbibliothek namens "Java Mail" [1], [2] aus "Java EE" [2] zu versenden. Die e-Mailklassen aus dieser Klassenbibliothek beginnen alle mit dem Namensraum "javax." (Top-level Paketname).
Die Spezifikationen der "enterprise edition (EE)" werden von der Open-source-Gemeinschaft "Eclipse Foundation" weiterentwickelt. Oracle USA besteht aber darauf, dass der Namensraum nicht mit "javax." mehr beginnen darf (wie auch, dass niemand den Namensraum "java." verwendet), da dies ein für Oracle geschützter Namen wäre; niemand möchte sich juristisch mit Oracle anlegen, sodass die Eclipse Foundation für die neuen Spezifikationen den Namensraum "jakarta." verwendet. "Jakarta" war in der Apache Software Foundation (ASF) ursprünglich die Bezeichnung für Java-bezogene Projekte und die ASF hat der Eclipse Foundation die Nutzung des Namens überlasen. "Java EE" wird daher durch "Jakarta EE" [4] abgelöst.
Das "Java Mail"-Paket heißt nunmehr "Jakarta Mail" [5], die Java-Klassenbibliothek [2] wurde unter Eclipse weiterentwickelt und kann in der Version 1.6.5 unter [6] heruntergeladen werden.
Während der Übergangszeit von "Java EE" auf "Jakarta EE" ist es daher immer wichtig für Softwareentwickler zu wissen, welches Mailpaket man verwendet, denn davon hängt ab, ob die Mail-Javaklassen mit dem Paketnamen "javax" (z.B. "javax.mail.Session") oder mit "jakarta" (z.B. "jakarta.mail.Session") beginnen.
Der "Namespace" ist daher das erste Problem, dessen man sich bewusst sein muss, wenn man das Mailpaket der "Enterprise Edition (EE)" verwendet. (Dasselbe gilt im übrigen für Java-basierte Webserver.)
Das zweite Problem im Zusammenhang mit dem EE-Mailpaket ist, dass die Klasse "javax.mail.Authenticator" bzw. das neuere Pendant "jakarta.mail.Authenticator" ein wenig eigenartig konzipiert wurde: es ist eine abstrakte Java-Klasse, die trotzdem alle Methoden konkret implementiert, allerdings mit der Java-Sichtbarkeit "protected", statt mit "public". Daher kann man nicht direkt auf diese Methoden zugreifen, sondern muss eine Java-Subklasse bilden, aus der man auf diese Methoden dann doch wieder zugreifen darf: man muss dabei die Methode "getPasswordAuthentication()" als öffentliche Methode implementieren. (Ziemlich unverständlich, aber so ist es nun einmal definiert worden.)
Normalerweise würde man in BSF4ooRexx für eine abstrakte Javaklasse einfach eine ooRexxklasse definieren, die die abstrakten Methoden in ooRexx implementiert, eine Rexxinstanz dann daraus erzeugen und mit BsfCreateRexxProxy(rexxObject,,"name.der.abstrakten.Javaklasse") dafür sorgen, dass im Hintergrund eine entsprechende Javaklasse automatisch erzeugt wird, in der die abstrakten Methoden dazu führen, dass das Rexxobjekt entsprechende Nachrichten mit entsprechenden Java-Argumenten geschickt erhält. Dies funktioniert aber bei der Klasse "javax|jakarta.mail.Authenticator" nicht, weil trotz der Tatsache, dass diese Klasse als abstrakte Java-Klasse definiert ist, es keine Java-Methoden gibt, die als "abstract" markiert sind!
Aus diesem Grund muss man in BSF4ooRexx zunächst eine "Proxy"-Javaklasse erzeugen, was mit der Routine "bsf.createProxyClass()" (vgl. auch das BSF4ooRexx-Beispiel "samples\3-010_clock.rxj") möglich ist (in BSF.CLS definiert). Hierbei kann eine beliebige (auch eine konkrete) Java-Klasse angegeben werden und eine kommaseparierte Liste von Methoden darin, die in einer ooRexx-Klasse implementiert sind. Dies geschieht mit:
jfclz=bsf.createProxyClass("javax.mail.Authenticator", , "getPasswordAuthentication")Die Java-Klasse, die retourniert wird, erwartet sich als erstes Argument ein RexxProxy, das man einfach mit BsfCreateRexxProxy(rexxObjekt) erzeugen kann.
Das dritte Problem: ich habe Ihnen eine Lösung geschickt, die sehr flexibel ist, in ooRexx mit "requires" eingebunden werden kann und deren öffentliche Routine "sendMailSSL" man beliebig oft anschließend aufrufen kann. Dabei wird automatisch beim erstmaligen Laden festgestellt, ob das installierte EE-Mailpaket für den Namensraum "javax" oder "jakarta" konzipiert war, der dann entsprechend beim Laden der Javaklassen verwendet wird. Es wird zudem ein Feature von ooRexx verwendet, das ich Ihnen nicht vermittelt habe, nämlich die lokale Umgebung des Pakets (des Rexxprogramms) selbst, auf das man mit ".context~package~local" Zugriff erhält: es handelt sich dabei um ein Directory-Objekt. Es ist dies das erste Umgebungsobjekt, das der ooRexx-Interpreter aufsucht, wenn er im Rexxprogramm ein Umgebungssymbol (die beginnen immer mit einem Punkt) findet und auflöst (der erste Punkt wird ignoriert, das verbleibende Symbol in Großbuchstaben wird als Index in einem der Umgebungsdirectories gesucht).
Das vierte Problem: damit man auf die EE-Mailklassen zugreifen kann, muss die entsprechende jar-Datei in die CLASSPATH-Umgebungsvariable *vor* dem Start des Programms aufgenommen werden, damit Java Klassen darin überhaupt finden kann. Das gilt für reine Javaprogramme wie auch für Rexxprogramme!
Hier eine Anleitung, wie man das unter Windows für "Java EE Mail" (Namensraum "javax.") schafft, d.h. Sie haben die jar-Datei "javax.mail.jar" [2] in dasselbe Verzeichnis wie das Programm gespeichert:
- Kommandozeile öffnen, in das Verzeichnis mit dem Programm wechseln und folgendes eingeben: set CLASSPATH=%CLASSPATH%;%cd%\javax.mail.jarAnschließend das Programm erfolgreich laufen lassen. :)
Anbei finden Sie folgende drei Programme:
"SendMailSSL.java": müssen Sie mit dem OpenJDK-Compiler zuerst kompilieren, z.B. mit "javax SendMailSSL.java", anschließend rufen Sie es mit "java SendMailSSL absenderEMail passwort empfaengerEMail Betreff e-Mail-Text" auf
"SendMailSSL.rex": ist eine 1:1-Übersetzung des Java-Programms nach ooRexx, Aufruf einfach mit "rexx SendMailSSL.rex absenderEMail passwort empfaengerEMail Betreff e-Mail-Text"
"sendEEMail.rex": das ist das ist die optimierte Version des Rexx-Programms, das automatisch den Namensraum bestimmt etc. und nach einem "::requires sendEEMail.rex" können Sie dann beliebig oft die öffentliche Routine "sendMailSSL(fromAddress, password, toAddress, subject, text)" aufrufen, wann immer Sie eine e-Mail über SSL/TLS schicken möchten!
Wenn Sie hier Fragen haben, dann scheuen Sie sich nicht, diese zu stellen! :)
Der Gruppe 2 viel Erfolg für das Abschließen des Projekts!
Mit freundlichem Gruß
Rony G. Flatscher
[1] "Java Mail (Java EE, namespace "javax."), Homepage: https://javaee.github.io/javamail/
[2] "Java Mail-Klassenbibliothek", Downloadlink, Version 1.6.2, Stand: 29.8.2018: https://github.com/javaee/javamail/releases/download/JAVAMAIL-1_6_2/javax.mail.jar
[3] https://de.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
[4] https://en.wikipedia.org/wiki/Jakarta_EE
[5] "Jakarta Mail (Jakarta EE, namespace "jakarta.", homepage: https://eclipse-ee4j.github.io/mail/
[6] "Java Mail-Klassenbibliothek", Downloadlink, Version 1.6.5, Stand: 10.3.2020: "https://repo1.maven.org/maven2/com/sun/mail/jakarta.mail/1.6.5/jakarta.mail-..."
-- __________________________________________________________________________________
Prof. Dr. Rony G. Flatscher Department Wirtschaftsinformatik und Operations Management Institut für Wirtschaftsinformatik und Gesellschaft D2c 2.086 WU Wien Welthandelsplatz 1 A-1020 Wien/Vienna, Austria/Europe
http://www.wu.ac.at __________________________________________________________________________________