Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Zugriff auf externe .JAR-Files (POP3, SMTP)

<< < (2/8) > >>

eknori:
Hey Manfred,

 8) dann mache es gleich richtig und baue eine Tool, daß sowohl POP3 Konten abfragen kann, als auch das SMTP AUTH ersetzt. Dann kann man sich das ´Gedaddel mit pullmail und Co sparen   :D

Manfred Dillmann:
Hallo Ulrich,

hörst Du inzwischen wieder was?  ;)

>>sowohl POP3 Konten abfragen kann, als auch das SMTP AUTH ersetzt.<<

Dann müsste das Tool ja quasi ein SMTP-Server sein. So mit Listener-Task. Du willst ja Deine Mails vom Domino-Server dort "abgeben" (quasi Relayen) und das Tool sollte das dann mit Auth beim Provider abliefern, richtig?

Feine Idee, aber ich bekomme im Moment nicht mal den "einfachen Teil" gebacken...

Manfred

eknori:
du machst das schon, da habe ich gar keine Zweifel  :D

Marinero Atlántico:
es gibt schon ein paar Beispiele.
Z.B.:
http://www.ftponline.com/javapro/2004_01/online/javamail_kjones_01_28_04/

Ich würde darüber nachdenken es erst einmal ausserhalb von Notes (Eclipse) zu machen.
Dann die Klassen in ein jar packen und in das Projekt importieren.

Die Klassen haben einen Konstruktor mit public. Und ein paar public Methoden, die von dem Notes-Agenten angesprochen werden.

Alles was du in Eclipse in das Projekt importieren musst, sind die notes.jar sowie die paar extra Mail-jars, die du ja schon gefunden hast.

Gruß axel

Marinero Atlántico:
Noch ein paar interessante issues zum classloading:
Classloaders kann man sich als so eine Art java.util.HashMap vorstellen.
Ein bischen wie List in LotusScript.
Also jede Klasse hat einen key, unter der sie referenziert werden kann (und dann geladen). Der key ist der Name. Also z.B. java.util.Map ist key und value ist die ganze Klasse mit diesem Namen.
Die Klassen werden nicht direkt geladen, sondern wenn sie benötigt werden.

Sobald du sowas machst wie

--- Code: ---StringBuffer buf = new StringBuffer();

--- Ende Code ---
beginnt die VM die HashMaps der Classloader zu durchforsten, ob sie die Klasse StringBuffer irgendwo finden kann.
Sie fängt mit dem untersten Classloader an. (s.o. 1. Bootstrap ClassLoader).
Sie findet java.lang.StringBuffer im untersten Classloader (java.lang.* steht implizit in jedem Import) und läd die Klasse.

Eine Klasse de.img.util.PropertiesFile wird vielleicht erst im 4. oder 5. Classloader gefunden.
Wird eine Klasse gar nicht in den ClassLoadern gefunden, wird eine ClassNotFound Exception geworfen.
Anfänger denken manchmal, dass die Anwendung schneller wird, wenn man die import statements so definiert:

--- Code: ---import java.util.*;

--- Ende Code ---
statt:

--- Code: ---import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import java.util.HashSet;

--- Ende Code ---
Das ist nicht schneller. Die Klasse wird tatsächlich erst geladen, wenn sowas wie

--- Code: ---StringBuffer buf = new StringBuffer();

--- Ende Code ---
da steht.

Jede Klasse spezifisch zu importieren ist sogar deutlicher. Ausserdem bieten moderne IDEs auto-completion features an, so dass kein Mensch mehr import statements schreibt, sondern z.B. bei Eclipse auf die gelbe Glühbirne klickt.

Es gibt ein teuflisches gotcha im Kontext von hot-deployment auf J2EE Servern, aber das sag ich jetzt nicht.

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete