SuSE Linux, MOCCA Error Code 2000

  • Der Browser? Da gibt's ein kleines Problem. Das SuSE Original verwendet /etc/alternatives/javaplugin -> /usr/lib/jvm/jre-1.6.0-openjdk/lib/i386/IcedTeaPlugin.so Allerdings! In der "großartigen" superaktuellen Version frisch von Oracle findet sich alles mögliche, nur kein "Eistee". Nichts was IcedTeaPlugin.so oder auch nur ähnlich heißen würde. Was konkret, welche .so Datei sollte denn statt dessen verwendet werden?


    Also eines trau ich mich zu behaupten: MOCCA unter Linux mag funktionieren, aber nur mit "halbem Informatikstudium"...

  • Hallo,
    ...Was konkret, welche .so Datei sollte denn statt dessen verwendet werden...
    Sollte die Datei libjavaplugin_oji.so von der Oracle-JRE sein.


    Ich verwende Archlinux mit der Oracle-JRE Version 1.6.0_21, MOCCA funktioniert bei mir korrekt.


    Für Linux-Anwender ist unter Umständen dieser Thread von Bedeutung da es keine Lösung bzw. nur eine Lösung für Windows gibt.
    http://alt.buergerkarte.at/mvn…rum/viewthread_thread,174


    lG

  • IcedTeaPlugin ist die freie Implementierung des Java-Browserplugins und Teil des OpenJDK. libjavaplugin_oji ist das alte Sun Java-Browserplugin und /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so ist das aktuelle ('next generation') Javaplugin. Siehe auch http://www.java.com/en/download/help/new_plugin.xml
    Mit dem Befehl 'update-alternatives' bzw. 'update-java-alternatives' kann das verwendete Plugin einfach festgelegt werden. Für Firefox in Ubuntu zb. 'update-alternatives --config mozilla-javaplugin.so' und danach das SUN plugin auswählen.

  • Danke für alle Hinweise und Ratschläge, aber der Fehler bleibt... unverändert! Es bedeutet auch, dass die top-aktuelle SuSE Version 11.3 MOCCA dezidiert NICHT unterstützt! Mag sein, nach etlichen komplizierten Spezialumbauten und Versionskontrollen. Ehrlich gesagt - ich mag nicht mehr und empfehle bis auf weiteres (in dieser Angelegenheit)... WIndows. Das kostet zwar, tut aber auch. OK, die Open-Source Community wird mir das wahrscheinlich sehr übel nehmen. Aber wollt ihr bei euren Autos oder Fahrrädern so rumbasteln nur um von A nach B zu kommen? Mit anwenderlichen Grüßen ;-))
    und trotz allem: take it easy! ;-))

  • Hallo,


    bin selbst vor einigen Tagen mit MOCCA "zwangsbeglückt" worden, da ja G3 karten nicht mehr von der Linuxversion von trustDesk unterstützt werden.


    Habe daher diesen Thread mit Spannung gelesen und "nachgebastelt".
    Selbst für mich, als "halben Informatiker" und geschulten Linux-Administrator war es teilweise nicht ganz leicht. Schon gar nicht die Argumentation zu verstehen, warum ich statt eines tollen openJRE plötzlich Oracle-Software benutzen soll oder warum es nötig ist, für eine externe Software die Plugins meines Browsers umzukrempeln...


    Aber genug des Smalltalks!
    Auch meine Bastelversuche blieben fruchtlos. Nachdem ich festgestellt hatte, dass die x86 version der JRE6_21 gar keine Plugins mitliefert, hab ich es natürlich mit der 32 bit Variante probiert, woraufhin mein Firefox meldet, er könne die Lib nicht laden (wrong ELF Class: 32).
    Wenig überraschend...


    Zur Information: auch ich benutze SuSE 11.3 mit einer x86 Architektur, auch bei mir versagt MOCCA trotz aller erdenklichen Kopfstände...


    Inzwischen überlege ich ernsthaft die neue Version der BKU von ITSolution zu kaufen...


    Frage an die Entwickler von MOCCA:
    Warum versteift ihr euch so auf Java? Ich persönlich habe beruflich wie privat beste Erfahrungen mit C++ bzw. Qt in puncto Plattformunabhängigkeit gemacht...

  • off topic, für alle die's interessiert: Ich verwende regelmäßig Linux, FreeBSD und Windows, durchaus mit etlichen Erfolgserlebnissen. Seit der Gründung im Jahr 2000 bei der Linux-User Group St. Pölten und auch beruflich einiges an Hard- und Software "gesehen". Mittlerweile "alter Hase" und manchmal vielleicht recht "eigenwillige Ansichten" ;-)))

  • Tutu mir Leid, aber ich kann nicht nachvollziehen, wie dass in meinem Fall helfen soll.
    Eine deinstallation der IcedTea-Pakete ändert nichts an der Tatsache, dass die aktuelle JRE-Version von Oracle in der 64bit-Variante kein Plugin mitliefert und das 32bit-Plugin von Firefox nicht akzeptiert wird...

  • Was ganz grundsätzliches: Eigentlich hat es ja einen Sinn (oder doch nicht???), dass die Distributionen mit bestimmten Java-Engines daherkommen. Natürlich könnten goldfinger, ich und weiß noch wer aller hergehen und bist zum "Geht nicht mehr" an unserer Linux-Installation manipulieren. Dann geht - eventuell - die BKU MOCCA. Aber wer weiß, was dann alles wieder __nicht__ geht!? Und ich wäre ehrlich gesagt recht sauer, wenn dann zwar die BKU, nicht jedoch die JDBCs funktionieren würden, sprich kein Datenbankzugriff mit OpenOffice (jedenfalls nicht mit Java). Strapazierte ich schon den Vergleich mit den Automarken? Für jede Automarke eine eigene Spezialautobahn mit eigens konstruiertem Fahrbahnbelag? Ein Java für MOCCA, ein anderes Java für JDBC, wieder ein anderes für weißichwas? Dass kann's doch nicht sein...

  • Meines Wissens nach (so habe auch ich die letzten Postings interpretiert) ist in den Sun/Oracle Java Paketen der SUSE Distribution dass plugin sehr wohl enthalten. Sun Java unterstützt seit Java SE 6 Update 12 Build 02 64bit Browser sowohl unter Linux als auch unter Windows. Wir testen MOCCA in Linux unter Ubuntu, Kubuntu und Gentoo. Andere Distributionen können wir daher leider nicht offiziell supporten, haben aber MOCCA selbst schon erfolgreich mit SUSE Linux verwendet.

  • Zitat

    Meines Wissens nach (so habe auch ich die letzten Postings interpretiert) ist in den Sun/Oracle Java Paketen der SUSE Distribution dass plugin sehr wohl enthalten. Sun Java unterstützt seit Java SE 6 Update 12 Build 02 64bit Browser sowohl unter Linux als auch unter Windows.


    Wenn Sie das so sehen, bitte ich Sie, das auf der Oracle-Seite angebotene selbstextrahierende RPM für x86-Architekturen zu laden und zu installieren.
    (http://java.com/de/download/li…p?locale=de&host=java.com)


    Dort sieht man folgenden Hinweis: "Bitte verwenden Sie die 32-Bit-Version für Java-Applet- und Java Web Start-Support. "


    Nach der Installation überprüft man dann /usr/java/jre1.6.0_21/plugin und kann feststellen, dass dort kein Pfad "i586" etc. zu einer entsprechenden .so existiert.
    Wie gesagt: bei der 32bit- Variante existiert diese Datei sehr wohl, wird aber von Firefox abgelehnt, da es sich eben um eine 32bit Bibliothek handelt.
    (Und ich werde sicher nicht wegen der BKU auf eine 32bit-Variante von Firefox umsteigen, hier stimme ich mit dem Autobeispiel von wilfrid.eu voll überein).


    Zitat

    Wir testen MOCCA in Linux unter Ubuntu, Kubuntu und Gentoo. Andere Distributionen können wir daher leider nicht offiziell supporten, haben aber MOCCA selbst schon erfolgreich mit SUSE Linux verwendet.


    Interesannt! Welche Plattform, Architektur, JRE-Version (Bezugsquelle), Umgebung etc.?

  • Kleines Update:


    Tatsächlich liefert SuSE 11.3 in der Distribution ein Sun-Package für Java mit.
    Name: java-1_6_0-sun
    Wichtig! Auch java-1_6_0-sun-plugin mitinstallieren!
    Dieses Paket enthält die Datei "/usr/lib64/jvm/java-1.6.0-sun-1.6.0/jre/lib/amd64/libnpjp2.so".
    Wird diese Datei im Firefox Plugi-Ordner verlinkt, operiert Firefox tatsächlich mit Sun-Java.


    War etwas Detektivarbeit auf die Datei zu kommen...


    Mit diesem Plugin läuft MOCCA jetzt einwandfrei als Browserapplet(!!).
    Die lokale Software - benötigt für Online-Bnking etc. - springt aber immer noch mit dem ursprünglichen fehler ab.


    Mein Verdacht: möglicherweise startet MOCCA WebStart in der falschen JRE am Rechner, bin aber noch am Suchen wie man dem Rechner beibringen soll, ausgerechnet die WebStart mit Sun auszuführen... (Hinweise?! ;) )

  • Letzter Stand der Dinge bei mir:
    about:plugins liefert unter anderem


    Java(TM) Plug-in 1.6.0_21
    Beschreibung: The next generation Java plug-in for Mozilla browsers.
    Speicherort: /usr/lib/jvm/java-1.6.0-sun-1.6.0/jre/lib/i386/libnpjp2.so


    Bringt aber auch nicht den gewünschten Erfolg, es bleibt beim Fehler 2000. Es spielt übrigens auch keine Rolle welcher Browser verwendet wird, Google-Chrome und Firefox handeln da nicht anders. Übrigens: MOCCA Zertifikat ist brav als vertrauenswürdige CA installiert und "selbstverständlich" liefert http://127.0.0.1:3495/ die gewünschte Anzeige (inkl. Pinverwaltung).

  • So, geschafft :))


    Was leider nicht geht, ist im shortcut am Desktp einfach Arbeitsverzeichnis oder Befehl zu ändern.
    Diese Versuche schlugen fehl; entweder startet das ding dann gar nicht (X-window fehler) oder unter openJRE...


    was funktioniert ist folgendes Skript:

    Shell-Script
    1. #!/bin/bash
    2. /usr/lib64/jvm/java-1.6.0-sun-1.6.0/jre/bin/javaws -verbose "/home/daniel/.netx/cache/http/webstart.buergerkarte.at/mocca/webstart/mocca.jnlp" &


    "-verbose" kann man auch weglassen...


    nur so startet (bei mir) die BKU richtig. Es funktioniert NICHT mit "cd" und dann "javaws ..." bzw. mit "./javaws ..."!


    Das Skript kann irgendow liegen und auch per Desktop-Link aufgerufen werden.
    Allerdings tritt sporadisch oben erwähnter x-window fehler auf, hier hilft dann ein Neustart. Hier müsste man noch genauer forschen (Debugger etc.).


    In der Regel startet man die BKU jedoch nur einmal, was bisher keine Probleme bei mir machte...

  • Normalerweise wird beim Installieren des Pakets der Alternatives-Link für javaws auf <JAVA_HOME>/jre/bin/javaws gesetzt und javaws ist somit am Pfad und kann von überall aufgerufen werden.


    Falls Sie keinen Desktop-Shortcut für MOCCA haben können Sie die Applikation entweder aus dem Applikationscache starten (erreichbar über das Java Control Panel > Allgemein > Temporäre Internetdateien > Anzeigen... oder selbst als webstart Applikation über http://webstart.buergerkarte.at/mocca/webstart/player.jnlp ) oder einfach in der Konsole folgenden Befehl eingeben:


    javaws http://webstart.buergerkarte.at/mocca/webstart/mocca.jnlp

  • ja, danke; ich wieß wie Desktoplinks zu bearbeiten sind :)


    die Befehlsänderung an sich ist durchführbar, liefert jedoch (zumindest bei mir) nicht das gewünschte Ergebnis.


    Warum ich openJRE entfernen sollte ist mir ein Rätsel. Was wenn ich Funktionen der openJRE brauche?
    Die Philosophie "entfernen Sie alles was wir nicht möchten, sonst können sie unsere Software nicht verwenden" hat IMHO in diesem Jahrhundert nichts mehr verloren, es sollte Aufgabe eines Entwicklers sein kompatible Produkte herzustellen.
    Aber diese Diskussion wurde in diesem Thread schon genug angeschnitten und würde offtopic führen...


    Ich habe auch keine Lust mehr weiter daran herumzutüfteln, ist nicht meine Aufgabe.
    Für mich selbst habe ich einen brauchbaren Ansatz gefunden (schon das wäre nicht meine Aufgabe gewesen...). Ob dies gut genug für Andere ist oder weiterentwickelt werden soll ist Sache der Entwickler...