-------- Forwarded Message -------- Subject: javax.mail Date: Mon, 25 Jan 2021 12:40:38 +0100 From: fabian-fuchs@a1.net To: 'Rony G. Flatscher' Rony.Flatscher@wu.ac.at
Sehr geehrter Herr Flatscher,
die folgende Email wäre natürlich für die Email-Liste bestimmt gewesen.
Leider kommt es dabei immer zu einer Spam Meldung und sie wird nicht verschickt.
137.208.116.20 does not like recipient.
track-id=1611572987:8278:smarthub88:80.110.97.62:1
Remote host said: 553 5.3.0 aj2020w@alice.wu-wien.ac.at... Spam blocked see: :{{http://spamcop.net/bl.shtml?195.3.96.115
Giving up on 137.208.116.20.
SSL=NO
Deswegen wende ich mich jetzt direkt an Sie.
Mit freundlich Grüßen,
Fabian Fuchs
Liebe Kollegen/innen
leider haben wir es noch immer nicht geschafft ein voll funktionsfähiges javax.mail Programm in oorexx zu implementieren.
Da wir nicht vor einem einzigen Problem stehen, sondern die Implementierung nicht schaffen, werde ich kurz die java Codezeilen erklären:
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(from,password) } });
Als erstes wird die Session Klasse aufgerufen mit der Methode getDefaultInstance Die getDefaultInstance Methode besitzt zwei Argumente die Properties und Authenticator Properties sind vorher schon definiert worden. Der Authenticator ist eine eigene Klasse und ruft die Methode getPasswordAuthentication auf. getPasswordAuthentication holt sich dann aus der subklasse PasswordAuthentication die passenden Werte.
Im folgende noch unsere Rexx Codezeilen:
session = bsf.loadclass("javax.mail.Session")
Auth = BSFCreateRexxProxy("javax.mail.Authenticator")
P = BSFCreateRexxProxy("PasswordAuthentication")
session~getDefaultInstance(props, )
::class javax.mail.Authenticator
::method getPasswordAuthentication
call PasswordAuthentication
::class PasswordAuthentication
::method getUsername
expose username
username = (" mailto:oorexx1@gmail.com oorexx1@gmail.com")
::method getPassword
expose password
password = ("xxxxx")
Wie scheiten jetzt daran, die Klassen Authenticator und PasswordAuthentication richtig zu verbinden. Außerdem bekommen wir wenn wir die Methoden aus unseren Klassen ausführen wollen immer eine Fehlermeldung. Z.B P~getPassword -> method: [GETPASSWORD] not found or execution error!??
Ich hoffe meine Erklärung ist verständlich; für Rückfragen stehe ich natürlich gerne zur Verfügung.
Mit freundlichen Grüßen,
Fabian Fuchs
Liebe Herr Fuchs,
bitte geben Sie folgende Informationen bekannt:
* .bsf4rexx~display.version * URL zum Mail-Paket und URL zu den Javadocs * vollständiges Rexx-Programm (sofern noch Teile fehlen) * bitte Ihren Code in folgendes "Sandwich" stellen und vollständige Fehlermeldung geben, hier der Sandwich-Code:
signal on syntax ... Ihr Code, in dem der Fehler auftritt ... exit
syntax: co=condition("object") -- get condition data say ppJavaExceptionChain(co,.true) raise propagate -- jetzt soll ooRexx seine Fehlerbehandlung vornehmen
---
Sollten Sie ein fehlerfrei laufendes Javaprogramm haben, dann schicken Sie es sicherheitshalber auch gleich mit!
Mit freundlichem Gruß
Rony G. Flatscher
On 25.01.2021 12:59, Rony G. Flatscher wrote:
-------- Forwarded Message -------- Subject: javax.mail Date: Mon, 25 Jan 2021 12:40:38 +0100 From: fabian-fuchs@a1.net To: 'Rony G. Flatscher' Rony.Flatscher@wu.ac.at
Sehr geehrter Herr Flatscher,
die folgende Email wäre natürlich für die Email-Liste bestimmt gewesen.
Leider kommt es dabei immer zu einer Spam Meldung und sie wird nicht verschickt.
137.208.116.20 does not like recipient.
track-id=1611572987:8278:smarthub88:80.110.97.62:1
Remote host said: 553 5.3.0 aj2020w@alice.wu-wien.ac.at... Spam blocked see: :{{http://spamcop.net/bl.shtml?195.3.96.115
Giving up on 137.208.116.20.
SSL=NO
Deswegen wende ich mich jetzt direkt an Sie.
Mit freundlich Grüßen,
Fabian Fuchs
Liebe Kollegen/innen
leider haben wir es noch immer nicht geschafft ein voll funktionsfähiges javax.mail Programm in oorexx zu implementieren.
Da wir nicht vor einem einzigen Problem stehen, sondern die Implementierung nicht schaffen, werde ich kurz die java Codezeilen erklären:
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(from,password) } });
Als erstes wird die Session Klasse aufgerufen mit der Methode getDefaultInstance Die getDefaultInstance Methode besitzt zwei Argumente die Properties und Authenticator Properties sind vorher schon definiert worden. Der Authenticator ist eine eigene Klasse und ruft die Methode getPasswordAuthentication auf. getPasswordAuthentication holt sich dann aus der subklasse PasswordAuthentication die passenden Werte.
Im folgende noch unsere Rexx Codezeilen:
session = bsf.loadclass("javax.mail.Session")
Auth = BSFCreateRexxProxy("javax.mail.Authenticator")
P = BSFCreateRexxProxy("PasswordAuthentication")
session~getDefaultInstance(props, )
::class javax.mail.Authenticator
::method getPasswordAuthentication
call PasswordAuthentication
::class PasswordAuthentication
::method getUsername
expose username
username = (" mailto:oorexx1@gmail.com oorexx1@gmail.com")
::method getPassword
expose password
password = ("xxxxx")
Wie scheiten jetzt daran, die Klassen Authenticator und PasswordAuthentication richtig zu verbinden. Außerdem bekommen wir wenn wir die Methoden aus unseren Klassen ausführen wollen immer eine Fehlermeldung. Z.B P~getPassword -> method: [GETPASSWORD] not found or execution error!??
Ich hoffe meine Erklärung ist verständlich; für Rückfragen stehe ich natürlich gerne zur Verfügung.
Mit freundlichen Grüßen,
Fabian Fuchs
--
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 __________________________________________________________________________________
Sehr geehrter Herr Flatscher,
Hier die urls zu den Mail-Paketen und den javadocs:
https://javaee.github.io/javamail/ https://javaee.github.io/javamail/ --javax.mail Paket
https://javaee.github.io/javamail/docs/api/javax/mail/Authenticator.html#Au thenticator-- https://javaee.github.io/javamail/docs/api/javax/mail/Authenticator.html#Aut henticator-- --Authenticator Klasse
https://javaee.github.io/javamail/docs/api/javax/mail/PasswordAuthentication .html --PasswordAuthentication Klasse
https://docs.oracle.com/javaee/6/api/javax/mail/Session.html#getTransport(j avax.mail.Address) https://docs.oracle.com/javaee/6/api/javax/mail/Session.html#getTransport(ja vax.mail.Address) Session Klasse
https://docs.oracle.com/javaee/6/api/javax/mail/internet/MimeMessage.html -- MimeMessage Klasse
https://docs.oracle.com/javaee/6/api/javax/mail/internet/InternetAddress.htm l -- InternetAddress Klasse
https://docs.oracle.com/javaee/5/api/javax/mail/Message.RecipientType.html --RecipientType Klasse
Fehlermeldung mit syntax on:
/////////////////////////////////////// Environment: [ooRexx 5.0.0 r12142 (20 Dec 2020) / BSF 641.20201217 / Java 1.8.0_191, 32-bit / Windows 10.0.18363]
showing Java exception chain (trigger exception at bottom) ...
-------> (Java exception # 1) caused by: [org.apache.bsf.BSFException@19bb367]:
org.apache.bsf.BSFException: BSF4ooRexx subfunction "invoke":
bean: [org.rexxla.bsf.engines.rexx.RexxProxy@110406] --> type: <org.rexxla.bsf.engines.rexx.RexxProxy>
method: [GETPASSWORD] not found or execution error!
-> check method name=[GETPASSWORD] (caseless o.k., but correct spelling?)
<------- (Java exception # 1)
-------- stack trace from [org.apache.bsf.BSFException@19bb367]:
org.apache.bsf.BSFException: BSF4ooRexx subfunction "invoke":
bean: [org.rexxla.bsf.engines.rexx.RexxProxy@110406] --> type: <org.rexxla.bsf.engines.rexx.RexxProxy>
method: [GETPASSWORD] not found or execution error!
-> check method name=[GETPASSWORD] (caseless o.k., but correct spelling?)
at org.rexxla.bsf.engines.rexx.RexxReflectUtil.throwNotFoundBSFException(RexxRe flectUtil.java:800)
at org.rexxla.bsf.engines.rexx.RexxReflectJava7.reflectMethod(RexxReflectJava7. java:1473)
at org.rexxla.bsf.engines.rexx.RexxReflectJava7.reflect(RexxReflectJava7.java:4 34)
at org.rexxla.bsf.engines.rexx.RexxAndJava.javaCallBSF(RexxAndJava.java:3614)
\\\\\\\\\\\\\\\\\\\\ ... end of Java exception chain.
Process finished with exit code -40
Im Anhang finden Sie unser Rexx-Programm sowie das Java-Programm
Mit freundlich Grüßen,
Fabian Fuchs
Von: Aj2020w aj2020w-bounces@alice.wu-wien.ac.at Im Auftrag von Rony G. Flatscher Gesendet: Montag, 25. Jänner 2021 15:37 An: aj2020w@alice.wu-wien.ac.at Betreff: Re: [Aj2020w] Fwd: javax.mail
Liebe Herr Fuchs,
bitte geben Sie folgende Informationen bekannt:
* .bsf4rexx~display.version * URL zum Mail-Paket und URL zu den Javadocs * vollständiges Rexx-Programm (sofern noch Teile fehlen) * bitte Ihren Code in folgendes "Sandwich" stellen und vollständige Fehlermeldung geben, hier der Sandwich-Code:
* signal on syntax * ... Ihr Code, in dem der Fehler auftritt ... * exit * * syntax: * co=condition("object") -- get condition data * say ppJavaExceptionChain(co,.true) * raise propagate -- jetzt soll ooRexx seine Fehlerbehandlung vornehmen *
---
Sollten Sie ein fehlerfrei laufendes Javaprogramm haben, dann schicken Sie es sicherheitshalber auch gleich mit!
Mit freundlichem Gruß
Rony G. Flatscher
On 25.01.2021 12:59, Rony G. Flatscher wrote:
-------- Forwarded Message --------
Subject:
javax.mail
Date:
Mon, 25 Jan 2021 12:40:38 +0100
From:
fabian-fuchs@a1.net mailto:fabian-fuchs@a1.net
To:
'Rony G. Flatscher' mailto:Rony.Flatscher@wu.ac.at Rony.Flatscher@wu.ac.at
Sehr geehrter Herr Flatscher,
die folgende Email wäre natürlich für die Email-Liste bestimmt gewesen.
Leider kommt es dabei immer zu einer Spam Meldung und sie wird nicht verschickt.
137.208.116.20 does not like recipient.
track-id=1611572987:8278:smarthub88:80.110.97.62:1
Remote host said: 553 5.3.0 mailto:aj2020w@alice.wu-wien.ac.at aj2020w@alice.wu-wien.ac.at... Spam blocked see: :{{http://spamcop.net/bl.shtml?195.3.96.115
Giving up on 137.208.116.20.
SSL=NO
Deswegen wende ich mich jetzt direkt an Sie.
Mit freundlich Grüßen,
Fabian Fuchs
Liebe Kollegen/innen
leider haben wir es noch immer nicht geschafft ein voll funktionsfähiges javax.mail Programm in oorexx zu implementieren.
Da wir nicht vor einem einzigen Problem stehen, sondern die Implementierung nicht schaffen, werde ich kurz die java Codezeilen erklären:
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(from,password) } });
Als erstes wird die Session Klasse aufgerufen mit der Methode getDefaultInstance Die getDefaultInstance Methode besitzt zwei Argumente die Properties und Authenticator Properties sind vorher schon definiert worden. Der Authenticator ist eine eigene Klasse und ruft die Methode getPasswordAuthentication auf. getPasswordAuthentication holt sich dann aus der subklasse PasswordAuthentication die passenden Werte.
Im folgende noch unsere Rexx Codezeilen:
session = bsf.loadclass("javax.mail.Session")
Auth = BSFCreateRexxProxy("javax.mail.Authenticator")
P = BSFCreateRexxProxy("PasswordAuthentication")
session~getDefaultInstance(props, )
::class javax.mail.Authenticator
::method getPasswordAuthentication
call PasswordAuthentication
::class PasswordAuthentication
::method getUsername
expose username
username = (" mailto:oorexx1@gmail.com mailto:oorexx1@gmail.com oorexx1@gmail.com mailto:oorexx1@gmail.com ")
::method getPassword
expose password
password = ("xxxxx")
Wie scheiten jetzt daran, die Klassen Authenticator und PasswordAuthentication richtig zu verbinden. Außerdem bekommen wir wenn wir die Methoden aus unseren Klassen ausführen wollen immer eine Fehlermeldung. Z.B P~getPassword -> method: [GETPASSWORD] not found or execution error!??
Ich hoffe meine Erklärung ist verständlich; für Rückfragen stehe ich natürlich gerne zur Verfügung.
Mit freundlichen Grüßen,
Fabian Fuchs
Lieber Herr Fuchs, liebe Studierende,
das Problem im Kern ist eines, das nicht einfach ist, geschuldet der Art und Weise wie Java/Jakarta EE Mail hier die Nutzung vorgesehen haben. Es ist keinesfalls für Sie oder andere Studierende zu diesem Zeitpunkt lösbar, damit Sie wissen, dass das nicht zu Ihrem Nachteil gereichen kann! :) Es erklärt für mich auch, warum der Bachelorstudent ein anderes Mailsystem gesucht und benutzt hat, daher auch mein Hinweis auf dessen Bachelorarbeit.
Anbei finden Sie eine funktionierende Lösung, die sowohl mit jakarta.mail-1.6.5-20200310.jar als auch mit javax.mail-1.6.2-20180829.jar getestet wurde:
* test.rex: zeigt beispielhaft, wie die Routine sendMailSSL() benutzt werden kann; Sie müssen aber eine gültige Absenderadresse mit dazupassenden Passwort und die Empfängeradresse angeben * sendMailSSL.rex: implementiert die öffentliche Routine sendMailSSL()
Wenn Sie Fragen zu der Lösung haben, dann stellen Sie sie und ich beantworte sie gerne hier.
Bitte nehmen Sie diese Lösung und vervollständigen Sie damit Ihr Projekt!
Mit freundlichem Gruß
Rony G. Flatscher
-- __________________________________________________________________________________
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 __________________________________________________________________________________
Sehr geehrter Herr Flatscher,
danke vielmals für die Hilfestellung! Wir stehen jetzt vor dem Problem, dass das Programm Jakarta nicht erkennt, obwohl es installiert ist und auch richtig funktioniert. Wir bekommen also immer wieder die Meldung:
"Cannot find the mail package for Java EE 8 or lower, nor for Jakarta EE 9 or higher"
Wie genau implementieren wir Jakarta in das Programm, so das es auch erkannt wird?
Mit freundlichen Grüßen, Luka Benzia
Von: Rony G. Flatscher Gesendet: Dienstag, 26. Jänner 2021 17:47 Betreff: [Aj2020w] Lösung "sendMailSSL.rex" (Re: Fwd: javax.mail
Lieber Herr Fuchs, liebe Studierende, das Problem im Kern ist eines, das nicht einfach ist, geschuldet der Art und Weise wie Java/Jakarta EE Mail hier die Nutzung vorgesehen haben. Es ist keinesfalls für Sie oder andere Studierende zu diesem Zeitpunkt lösbar, damit Sie wissen, dass das nicht zu Ihrem Nachteil gereichen kann! :) Es erklärt für mich auch, warum der Bachelorstudent ein anderes Mailsystem gesucht und benutzt hat, daher auch mein Hinweis auf dessen Bachelorarbeit. Anbei finden Sie eine funktionierende Lösung, die sowohl mit jakarta.mail-1.6.5-20200310.jar als auch mit javax.mail-1.6.2-20180829.jar getestet wurde: • test.rex: zeigt beispielhaft, wie die Routine sendMailSSL() benutzt werden kann; Sie müssen aber eine gültige Absenderadresse mit dazupassenden Passwort und die Empfängeradresse angeben • sendMailSSL.rex: implementiert die öffentliche Routine sendMailSSL() Wenn Sie Fragen zu der Lösung haben, dann stellen Sie sie und ich beantworte sie gerne hier. Bitte nehmen Sie diese Lösung und vervollständigen Sie damit Ihr Projekt! Mit freundlichem Gruß Rony G. Flatscher -- __________________________________________________________________________________
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 __________________________________________________________________________________
Lieber Herr Benzia,
On 28.01.2021 12:06, Luka Benzia wrote:
Wir stehen jetzt vor dem Problem, dass das Programm Jakarta nicht erkennt, obwohl es installiert ist und auch richtig funktioniert.
Wie stellen Sie fest, dass es "auch richtig funktioniert"?
Wir bekommen also immer wieder die Meldung:
"Cannot find the mail package for Java EE 8 or lower, nor for Jakarta EE 9 or higher"
Wie genau implementieren wir Jakarta in das Programm, so das es auch erkannt wird?
Das ist lediglich eine Frage des CLASSPATHs, der auf die entsprechende (javax oder jakarta) jar-Datei verweisen muss. Ist der Pfad korrekt angegeben in dem Prozess, in dem das Rexxprogramm läuft?
Mit freundlichem Gruß
Rony G. Flatscher
*Von: *Rony G. Flatscher mailto:Rony.Flatscher@wu.ac.at *Gesendet: *Dienstag, 26. Jänner 2021 17:47 *Betreff: *[Aj2020w] Lösung "sendMailSSL.rex" (Re: Fwd: javax.mail
Lieber Herr Fuchs, liebe Studierende,
das Problem im Kern ist eines, das nicht einfach ist, geschuldet der Art und Weise wie Java/Jakarta EE Mail hier die Nutzung vorgesehen haben. Es ist keinesfalls für Sie oder andere Studierende zu diesem Zeitpunkt lösbar, damit Sie wissen, dass das nicht zu Ihrem Nachteil gereichen kann! :) Es erklärt für mich auch, warum der Bachelorstudent ein anderes Mailsystem gesucht und benutzt hat, daher auch mein Hinweis auf dessen Bachelorarbeit.
Anbei finden Sie eine funktionierende Lösung, die sowohl mit jakarta.mail-1.6.5-20200310.jar als auch mit javax.mail-1.6.2-20180829.jar getestet wurde:
- test.rex: zeigt beispielhaft, wie die Routine sendMailSSL() benutzt werden kann; Sie müssen aber eine gültige Absenderadresse mit dazupassenden Passwort und die Empfängeradresse angeben
- sendMailSSL.rex: implementiert die öffentliche Routine sendMailSSL()
Wenn Sie Fragen zu der Lösung haben, dann stellen Sie sie und ich beantworte sie gerne hier.
Bitte nehmen Sie diese Lösung und vervollständigen Sie damit Ihr Projekt!
Mit freundlichem Gruß
Rony G. Flatscher
-- __________________________________________________________________________________ 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 http://www.wu.ac.at __________________________________________________________________________________
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.jar
Anschließend das Programm erfolgreich laufen lassen. :)
Anbei finden Sie folgende drei Programme:
1. "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 2. "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"
3. "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 __________________________________________________________________________________
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 __________________________________________________________________________________
Lieber Herr Fuchs,
hier zur Information, was geschehen ist:
Lieber Rony,
auf ALICE gibt's spamassassin daemon und auch überprüfung mailabsender über bekannte spammers listen. spamcop meldet absender IP als spammer bekannt weitere infos: http://spamcop.net/bl.shtml?195.3.96.115
lg
Wenn Sie auf den Link klicken, finden Sie dort einen weiteren Link mit dem Bericht über die IP-Adresse, die als Spammer derzeit kategorisiert ist.
Ad Spamassassin: https://spamassassin.apache.org/
Mit freundlichem Gruß
Rony G. Flatscher
On 25.01.2021 12:59, Rony G. Flatscher wrote:
-------- Forwarded Message -------- Subject: javax.mail Date: Mon, 25 Jan 2021 12:40:38 +0100 From: fabian-fuchs@a1.net To: 'Rony G. Flatscher' Rony.Flatscher@wu.ac.at
Sehr geehrter Herr Flatscher,
die folgende Email wäre natürlich für die Email-Liste bestimmt gewesen.
Leider kommt es dabei immer zu einer Spam Meldung und sie wird nicht verschickt.
137.208.116.20 does not like recipient.
track-id=1611572987:8278:smarthub88:80.110.97.62:1
Remote host said: 553 5.3.0 aj2020w@alice.wu-wien.ac.at... Spam blocked see: :{{http://spamcop.net/bl.shtml?195.3.96.115
Giving up on 137.208.116.20.
SSL=NO
Deswegen wende ich mich jetzt direkt an Sie.
Mit freundlich Grüßen,
Fabian Fuchs
Liebe Kollegen/innen
leider haben wir es noch immer nicht geschafft ein voll funktionsfähiges javax.mail Programm in oorexx zu implementieren.
Da wir nicht vor einem einzigen Problem stehen, sondern die Implementierung nicht schaffen, werde ich kurz die java Codezeilen erklären:
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(from,password) } });
Als erstes wird die Session Klasse aufgerufen mit der Methode getDefaultInstance Die getDefaultInstance Methode besitzt zwei Argumente die Properties und Authenticator Properties sind vorher schon definiert worden. Der Authenticator ist eine eigene Klasse und ruft die Methode getPasswordAuthentication auf. getPasswordAuthentication holt sich dann aus der subklasse PasswordAuthentication die passenden Werte.
Im folgende noch unsere Rexx Codezeilen:
session = bsf.loadclass("javax.mail.Session")
Auth = BSFCreateRexxProxy("javax.mail.Authenticator")
P = BSFCreateRexxProxy("PasswordAuthentication")
session~getDefaultInstance(props, )
::class javax.mail.Authenticator
::method getPasswordAuthentication
call PasswordAuthentication
::class PasswordAuthentication
::method getUsername
expose username
username = (" mailto:oorexx1@gmail.com oorexx1@gmail.com")
::method getPassword
expose password
password = ("xxxxx")
Wie scheiten jetzt daran, die Klassen Authenticator und PasswordAuthentication richtig zu verbinden. Außerdem bekommen wir wenn wir die Methoden aus unseren Klassen ausführen wollen immer eine Fehlermeldung. Z.B P~getPassword -> method: [GETPASSWORD] not found or execution error!??
Ich hoffe meine Erklärung ist verständlich; für Rückfragen stehe ich natürlich gerne zur Verfügung.
Mit freundlichen Grüßen,
Fabian Fuchs
-- __________________________________________________________________________________
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 __________________________________________________________________________________
-
fabian-fuchs＠a1.net -
Luka Benzia -
Rony G. Flatscher