Sidebar Plugin Phonebook

[Patrick Schneider]

Vielleicht gibt es vein OpenNTF bereits eine neuere Version vom Plugin?

Nee, leider nicht. Netterweise Ralf schon mal ausgeholfen und den Code angepasst.

@Ralf: Danke für die Anpassung.  Rein interessehalber: Könntest du die Anpassungen hier posten oder mir per PM zukommen lassen? Vielen Dank

[habemehl]

Wäre dem OpenSource gedanken nicht mehr geholfen, wenn Ralf die Änderung direkt als neue Version auf OpenNTF hochlädt? 

[Ralf_M_Petter]

Mit FP8 hat sich der Java Stack geändert, das wohl zur Folge hat, dass Dein Phonebook Plugin nicht mehr kompatibel ist.
Genau das sagt auch die Fehlermeldung:

lotus.domino.local.Document incompatible with lotus.domino.local.Session

Vielleicht gibt es vein OpenNTF bereits eine neuere Version vom Plugin?

Das ist nicht korrekt. Alle Plugins, mit jeder Menge Sidebarwidgets und anderen UI Erweiterungen für den Notesclient laufen ohne Änderung auch auf FP8. Es ist also irgendein Fehler, der jetzt erst durch FP8 schlagend wird.

Ich schau mir das mal kurz an, ob man das einfach flicken kann.

Grüße

Ralf

[(h)uMan]

Mit FP8 hat sich der Java Stack geändert, das wohl zur Folge hat, dass Dein Phonebook Plugin nicht mehr kompatibel ist.
Genau das sagt auch die Fehlermeldung:

lotus.domino.local.Document incompatible with lotus.domino.local.Session

Vielleicht gibt es vein OpenNTF bereits eine neuere Version vom Plugin?

Das ist nicht korrekt. Alle Plugins, mit jeder Menge Sidebarwidgets und anderen UI Erweiterungen für den Notesclient laufen ohne Änderung auch auf FP8. Es ist also irgendein Fehler, der jetzt erst durch FP9 schlagend wird.

Ich schau mir das mal kurz an, ob man das einfach flicken kann.

@Ralf: Wenn Du noch Infos und/oder Auszüge aus Logs benötigst: einfach melden

[Ralf_M_Petter]

Ich bin schon beim Debuggen, aber leider kann ich das Problem derzeit in der Entwicklungsumgebung nicht wirklich nachvollziehen. Was mir aber auffällt, das Widget ist extrem performanceungünstig programmiert. Sieht so aus, als ob der Entwickler demonstrieren wollte wie langsam Java sein kann, wenn man es nur ganz hart versucht. Die Hotspotengine gibt sich ja jede Menge Mühe, aber so einen Müll vom Performancestandpunkt habe ich schon ewig nicht mehr gesehen.

Ist das bei euch auch so furchtbar langsam? Ich meine 70.000 Adressen in meiner Demoumgebung sollten für meine Maschine ein Klacks sein.

Grüße

Ralf

[Ralf_M_Petter]

So habe jetzt mal die ärgsten Bugs beseitigt. Sollte jetzt um viele 100er mal schneller gehen. Natürlich wäre noch jede Menge Potential vorhanden, dass nochmals um den Faktor 10 oder mehr zu beschleunigen. Aber in meiner Umgebung läuft es damit halbwegs performant.

Probier es aus und wenn du Probleme hast, melde dich einfach. Übrigens falls du Fehlermeldungen mit Stacktraces postest, wäre es wichtig in Notes die Zeilennummern einzuschalten. Mit Unknown Source kann man halt nur bedingt etwas anfangen. Kann mir ehrlich gesagt nicht vorstellen, wie Ihr das Probleme mit dem Notesclient in den Griff bekommt, wenn das auch auf euren Arbeitspläten so konfiguriert ist.

Grüße

Ralf

P.S. Kennt sich jemand mit den Gepflogenheiten auf OpenNTF aus, wie man den Code wieder hochlädt. Würde das gerne zur Verfügung stellen, den auch wenn das jetzt alles Quick and Dirty war, ist es tausend mal besser als das was man derzeit herunterladen kann.

[(h)uMan]

So habe jetzt mal die ärgsten Bugs beseitigt. Sollte jetzt um viele 100er mal schneller gehen. Natürlich wäre noch jede Menge Potential vorhanden, dass nochmals um den Faktor 10 oder mehr zu beschleunigen. Aber in meiner Umgebung läuft es damit halbwegs performant.

Probier es aus und wenn du Probleme hast, melde dich einfach.

Läuft wieder und ist auch schneller

Allerbesten Dank, Ralf!!!

Übrigens falls du Fehlermeldungen mit Stacktraces postest, wäre es wichtig in Notes die Zeilennummern einzuschalten. Mit Unknown Source kann man halt nur bedingt etwas anfangen. Kann mir ehrlich gesagt nicht vorstellen, wie Ihr das Probleme mit dem Notesclient in den Griff bekommt, wenn das auch auf euren Arbeitspläten so konfiguriert ist.

Wo schalte ich die denn im Standard-Client ein?
Hab in den Vorgaben so nichts passendes gefunden.

P.S. Kennt sich jemand mit den Gepflogenheiten auf OpenNTF aus, wie man den Code wieder hochlädt. Würde das gerne zur Verfügung stellen, den auch wenn das jetzt alles Quick and Dirty war, ist es tausend mal besser als das was man derzeit herunterladen kann.

Kenne die Regularien nicht  Schreib doch einfach die Person an, die das Plugin dort reingestellt hat.

Ansonsten könnte Eknori noch Auskunft geben. Er hat ja bei OpenNTF schon was reingestellt.

[eknori]

Ich hole das noch einmal nach oben, weil ich gerade mit einem anderen Plugin in genau den gleichen Fehler gelaufen bin.

Habe das Plugin unter 9.0.1 ( ohne - FP7 ) duchgetestet. Da gibt es keinerlei Probleme.
Nach dem Update auf FP8 tritt der Fehler auf. Manchmal sofart nach Notes Start; teilweise auch erst zu einem späteren Zeitpunkt.

Hat irgendwer schon neuere Erkenntnisse, oder muß ich auf der grünen Wiese anfangen? Gibt es evtl. schon einen PMR dazu?

Der Fehler lässt sich zuverlässig reproduzieren, und er tritt unter FP8 mit sehr hoher Wahrscheinlichkeit auf. Mit FP8IF1 tritt er SOFORT auf.

Anmerkung:
Das in dem StackTrace die Zeilennummer im Code mit ausgegeben wird ist offensichtlich zuviel verlangt

[Tode]

@Ulrich: Gibt es die nette kleine Option "Compile Java code with Debugging information" für Plugins nicht, die bei Java- Agenten (Eigenschaften des Agenten) dafür sorgt, dass die Zeilennummer mit ausgegeben wird?

[eknori]

Ich habe das jetzt in meinem Plugin soweit runtergebrochen. Der Fehler tritt bei

Code

if (vweDocument.getDocument() != null && vweDocument.getDocument().getItemValue( ... blah blah

auf.

Mache ich statt dessen eine explizite Zuweisung

Code

Document temp_doc = vweDocument.getDocument();
if (temp_doc != null && temp_doc.getItemValue(" blah blah ... 

dann tritt der Fehler nicht mehr auf.

Evtl ist es im Phonebook eine ähnliche Konstellation.

[Pfefferminz-T]

Auf dieselbe Fehlermeldung läuft ein weiteres Tool eines Drittanbieters...

lotus.domino.local.Document incompatible with lotus.domino.local.Session

Sobald die Notes.jar vom FP8 (bzw. FP8IF1) durch die Datei vom FP7 (oder früher) ersetzt wird, funktioniert wieder alles.

LO9222
SPR # RGAUALXF5R

Beispielcode, mit dem das reproduziert werden kann, würde helfen.

[Martin4812]

Hallo,

Wir kennen das Problem mit 901FP8 in verschiedenen Varianten:

java.lang.ClassCastException: lotus.domino.local.Item incompatible with lotus.domino.local.Session
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.Document.getItems(Unknown Source)
   ...

java.lang.ClassCastException: lotus.domino.local.Document incompatible with lotus.domino.local.Session
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.DocumentCollection.getFirstDocument(Unknown Source)
   ...

java.lang.ClassCastException: lotus.domino.local.View incompatible with lotus.domino.local.Session
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.Session.FindOrCreate(Unknown Source)
   at lotus.domino.local.Database.getView(Unknown Source)
   ...

Um manche Varianten konnten wir bei uns herumprogrammieren, um einige aber nicht.
Leider ist unser Plugin recht umfangreich und braucht viel Umfeld so das wir diesem SPR keinen Beispielcode beifügen konnten.

Grüße, Martin

[eknori]

Sobald die Notes.jar vom FP8 (bzw. FP8IF1) durch die Datei vom FP7 (oder früher) ersetzt wird, funktioniert wieder alles.

LO9222
SPR # RGAUALXF5R

Ah, danke, dann hänge ich mich mal da dran.

Und, wie gesagt, ich habe unseren Code wie o.a. geändert und unser Plugin läuft nun, wie es soll.

[Pfefferminz-T]

Gerne, wie geschrieben wäre es gut, wenn man der IBM einen Code-Teil zur Verfügung stellen könnte, mit dem man das reproduzieren kann...

[eknori]

nun ja, das ist auch in meinem Fall leichter gesagt, als getan.

Schick denen doch das PhoneBook plugin

[Martin4812]

Hallo,

Das PhoneBook Plugin baucht wohl auch geeignete Datenbestände um das Problem zu zeigen. In einer sehr kleinen Spielumgebung sehen wir keine Probleme damit.

Grüße,
Martin

[eknori]

@Ralf: Kannst Du den überarbeiteten Code zur verfügung stellen, bitte? Dann pushe ich das nach ONTF.

[Pfefferminz-T]

Welche Schritte bei dem Sidebar PlugIn führen denn zu dem Fehler unter FP8? Die Version auf OpenNTF scheint ja noch die alte zu sein, da müsste de Fehler ja auftreten, oder?

Sind zusätzliche PlugIns/Widgets installiert? Wieviele User habt ihr ca. in den Adressbüchern, die ihr abfragt?

Ich nehme an, dass Phonebook wurde vorher in einer anderen Notes-Version auch schon verwendet? Mit welchem FP?

Danke!

[eknori]

Der Fehler wurde von IBM bestätigt. Ein Fix ist für FP9 vorgesehen.
Und da sich vermutlich niemand mit Support freiwillig an den SPR hängt, sehe ich die Chancen für einen IF auch als sehr gering an.

Mir hat man heute bei meinem PMR auch keinen Code abverlangt, weil die wohl schon wissen, wo der Hase begraben ist.
Zudem gibt es ja einen Workaround.

[eknori]

Na super. Nicht nur, daß Plugins unter bestimmten Konstellationen nicht mehr mit FP8 funktionieren; jetzt musste ich auch noch feststellen, daß mein template mit einer einzigen minimalen XPage fehler wirft. Die lässt sich im designer gar nicht erst öffnen. template zeigt buildfehler und auch "normale" designelemente verhalten sich "seltsam".
FP8 runtergeworfen und siehe da, alles funktioniert wieder.

Aus meiner Sicht kann ich vor FP8 im Client nur eindringlich warnen, sowohl in der Entwicklung als auch in einer Laufzeitumgebung.