Domino 9 und frühere Versionen > ND6: Entwicklung

Progressbar: ALternative zu .dlls = LS2J

(1/2) > >>

cgorni:
Hallo zusammen,

ich habe schon öfter nach einer Lösung für das Thema ProgressBar gesucht und immer das Übliche gefunden: NotesProgressBar/unsupported/.dll-Aufrufe.

Vor kurzem bin ich über eine Alternative gestolpert, die Java benutzt und LS2J:

http://www.nsftools.com/tips/NotesTips.htm#ls2jexamples

Die Beispielagenten sehen wirklich interessant aus: ein einfacher ProgressBar und eine Erweiterung mit Protokollfenster.

Allerdings habe ich nicht so viel Erfahrung mit LS2J (sprich: keine) und möchte bevor ich das in meinen Agenten standardmäßig einsetze mal nach den Erfahrungen bei euch nachfragen. Irgendwelche Probleme bei LS2J? Auch bei einer so eingeschränkten Lösung wie dieser?

Gruß,
Christian

Marinero Atlántico:

--- Zitat von: cgorni am 01.03.05 - 15:44:05 --- die Java benutzt und LS2J:

--- Ende Zitat ---
... kündige hiermit für das übernächste Woche ein Mini-Tutorial dazu an wie man mit JProfiler oder vergleichbaren Tools Memory Leaks aufspüren kann. LS2J ist hervorragend für diese Aufgabe ausgestattet:
Wenn ich die Diskussionen auf www.benpoole.com von Dez, Jan sowie die Erfahrungsberichte von Manfred Dillmann richtig verstanden habe, besitzt LS2J das coole feature, dass es quasi automatisch Memory Leaks erzeugt, es sei denn man programmiert sehr komplexen drumherum-code. :-)

Les dir das gut durch:
http://www.benpoole.com/weblog/200501162217#PostComments

Marinero Atlántico:
Memory Leaks ist quasi das übelste, was eine Plattform an bugs bieten kann.
Nach der Theorie ist ein Fehler desto kostengünstiger zu beheben je früher der Entwickler ihn feststellt.
Manche Fehler fallen schon beim kompilieren auf.
Andere bei Unit Tests.
Wieder andere bei Integrationstest.

Ein Memory Leak ist aber so geartet, dass das System immer mehr Speicher beansprucht ohne diesen freizugeben.
Irgendwann ist der der JVM zur Verfügung stehende speicher voll und es kommt zu einem java.lang.OutOfMemoryError extends java.lang.VirtualMaschineError.
Man muß dann diesen Computer wieder neu starten.
Das hat nix mit Java sondern mit LS2J zu tun.
Damit dies zuschlägt, muß das System eine Zeit laufen (bei Ben Poole waren es 3 Tage). So lange laufen Testmaschinen oft nicht, ohne dass sie durchgebootet werden.
Gemäß meinen Ermittlungen ist dieser fEhler auch nicht irgend so ein fun-Fehler, der schnell mal behoben ist, falls mal einer dazu Bock hat. Nein. Er ist tief verwoben mit dem Garbage Collector Verhalten in jeder Java Virtual Maschine. Ein architektonischer Supergau von Lotus sozusagen.
Profiler Tools wie JProfiler versprechen, dass man mit ihnen solche Fehler frühzeitig erkennen kann. Deshalb das Mini-Tutorial.

Axel

cgorni:
Hm,

passiert das auch, wenn ich Java-Only aufrufe, d.h. wenn das LS2J-Java selbst keine Domino-Klassen benutzt?

Im Fall der oben genannten Progressbar könnte das der Fall sein (habs noch nicht auf diesen Punkt hin untersucht). Hier werden ein paar Parameter übergeben und ein AWT-Fenster manipuliert.

Gruß,
C.

Marinero Atlántico:

--- Zitat von: cgorni am 01.03.05 - 16:41:16 ---Hm,

passiert das auch, wenn ich Java-Only aufrufe, d.h. wenn das LS2J-Java selbst keine Domino-Klassen benutzt?


--- Ende Zitat ---
Das ist ein sehr, sehr guter Punkt.
Es könnte gut sein, dass dies dann nicht passiert.
Kenn mich da nicht so aus. Werden dem LS2J-code nicht automatisch Referenzen aus der aufrufenden LotusScript code übergeben?
Muss nicht sein.
Jedenfalls werde ich das mit dem JProfiler mal durchspielen.
Der Zynismus meiner Postings steigt proportional mit dem Stress im Büro.  ;D

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite