StellwerkSim

Verfasst: **Sa Apr 20, 2013 3:10 pm**

Hallo zusammen,

zuerstmal: ich poste das hier nicht, weil ich ein unbekanntes Problem habe, sondern nur zur Info, da der Fehler nicht in der Sim, sondern im benutzten Java-Paket zu finden ist. Aber vielleicht interessiert es den ein oder anderen hier (z.B. Abrixas, der mir gestern im Chat versucht hat, mir direkt zu helfen (vielen Dank dafür

)

Leider habe ich es gestern nicht geschafft an dem Stellwerk-Abend teilzunehmen, da sich mein Rechner partout nicht mehr mit der Sim verbinden wollte

Starte ich eine Sim, bleibt der Startscreen immer bei 0% stehen (der Balken bewegt sich weiterhin - es wird aber nichts geladen).

Zugegeben, meine Konfiguration hört sich evtl. ein wenig exotisch an, aber prinzipiell läuft die Sim seit jeher bis gestern unproblematisch: Ich benutze Mageia 2 (Linux) mit dem Icedtea-Plugin.

Wenn ich firefox in der Konsole starte, bekomme ich Folgendes:

Code: Alles auswählen

[marc@Rechner ~]$ firefox
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.10) (fedora-40.b24.1.mga2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
*** Build: 4654
Mem @ Start 1 max: 915341312 free: 47047112 cur: 61669376
Mem @ Start 2 max: 915341312 free: 50016224 cur: 61669376
Exception in thread "GB load" javax.xml.parsers.FactoryConfigurationError: Provider com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl could not be instantiated: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.com.sun.org.apache.xerces.internal.jaxp)
        at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:132)
        at js.java.tools.xml.xmlreader.<clinit>(xmlreader.java:39)
        at js.java.schaltungen.gleisbild.gleisbildModelStore.getData(gleisbildModelStore.java:227)
        at js.java.schaltungen.gleisbild.gleisbildModelStore.access$100(gleisbildModelStore.java:31)
        at js.java.schaltungen.gleisbild.gleisbildModelStore$ioLoader.run(gleisbildModelStore.java:82)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.com.sun.org.apache.xerces.internal.jaxp)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
        at java.security.AccessController.checkPermission(AccessController.java:558)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:284)
        at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:291)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1563)
        at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:109)
        at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:151)
        at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:238)
        at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:126)
        ... 4 more

Nach langer Zeit der Fehlersuche habe ich das java-openjdk Paket, dass von Mageia angeboten wird 'downgegraded' und siehe da, die Sim startet wieder:

Code: Alles auswählen

[marc@Rechner ~]$$ firefox
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.9) (fedora-39.b24.1.mga2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
*** Build: 4654
Mem @ Start 1 max: 922746880 free: 51408952 cur: 62128128
Mem @ Start 2 max: 922746880 free: 55716112 cur: 62128128

Falls jemand von den Java-Experten hier in der Fehlermeldung nützliche Hinweise entdeckt, wo der Fehler liegen könnte, wäre ich für eine Meldung dankbar. Dann könnte ich das entweder den Jungs/Mädels von OpenJDK oder dem Mageia-Paket-Maintainer weitergeben...

Viele Grüße,
Marc

Verfasst: **Sa Apr 20, 2013 3:57 pm**

Hi,

der Fehler selbst ist ja offensichtlich: access denied
Frage ist natürlich woher der stammt, also was hier nicht ausgeführt werden darf. Mein Verständnis von Java geht nicht besonders tief, ich meine aber, daß diese Runtime Permissions über eine java.policy geregelt werden müssten. Mein erster Ansatz wäre also, mal diese Dateien vor und nach dem Update zu vergleichen. Die policy-Dateien müssten irgendwo in der java-Installation unter lib/security stehen. Ich würde vermuten, da wird irgendetwas geändert, was dann zu Problemen führt.

Servus
Heinz

Verfasst: **Sa Apr 20, 2013 4:35 pm**

Moin,

hast du mal Grando laufen lassen? Das trägt einige Permissions ein, evlt. löst das schon das Problem. Ansonsten müsste man wohl ein bisschen herumprobieren, welche Einträge dort fehlen.

Gruß,
DevonFrosch

Verfasst: **Sa Apr 20, 2013 4:37 pm**

hinz hat geschrieben:Mein erster Ansatz wäre also, mal diese Dateien vor und nach dem Update zu vergleichen.

Sehr interessant:

die 'alte' java.security unter /lib/security:

Code: Alles auswählen

# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.,\
               com.sun.xml.internal.,\
               com.sun.imageio.,\
               com.sun.istack.internal.,\
               com.sun.jmx.

die neue:

Code: Alles auswählen

# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.,\
               com.sun.xml.internal.,\
               com.sun.imageio.,\
               com.sun.istack.internal.,\
               com.sun.jmx.,\
               com.sun.org.apache.bcel.internal.,\
               com.sun.org.apache.regexp.internal.,\
               com.sun.org.apache.xerces.internal.,\
               com.sun.org.apache.xpath.internal.,\
               com.sun.org.apache.xalan.internal.extensions.,\
               com.sun.org.apache.xalan.internal.lib.,\
               com.sun.org.apache.xalan.internal.res.,\
               com.sun.org.apache.xalan.internal.templates.,\
               com.sun.org.apache.xalan.internal.xslt.,\
               com.sun.org.apache.xalan.internal.xsltc.cmdline.,\
               com.sun.org.apache.xalan.internal.xsltc.compiler.,\
               com.sun.org.apache.xalan.internal.xsltc.trax.,\
               com.sun.org.apache.xalan.internal.xsltc.util.,\
               com.sun.org.apache.xml.internal.res.,\
               com.sun.org.apache.xml.internal.serializer.utils.,\
               com.sun.org.apache.xml.internal.utils.,\
               com.sun.org.glassfish.

Und das selbe nochmal ein paar Zeilen tiefer...

Wenn man die zusätzlichen Zeilen aus der neuen Datei rauslöscht, startet die Sim auch mit dem aktuellen openJDK Paket. Das ist ja nun ein Ansatzpunkt für weitere Nachforschungen

Vielen Dank für den Tip

Verfasst: **Sa Apr 20, 2013 4:43 pm**

OpenJDK 1.6 funktioniert nicht. Erst OpenJDK 1.7 oder aber Sun JDK 1.6 laufen. Die Forensuche dürfte dazu weitere erfolglose Versuche liefern um das zu bestätigen. Die Frage nach dem Warum erklärt sich da leider auch von selbst: Wenn das Warum klar wäre, wäre es ja gelöst. Da aber Java 6 ohnehin EOL hat, wird es da wohl auch keine Korrekturen mehr geben - weder von Java-Seite noch vom Sim. Vielmehr wird STS mittelfristig Java 7 voraussetzen.

Verfasst: **Sa Apr 20, 2013 5:04 pm**

DevonFrosch hat geschrieben:hast du mal Grando laufen lassen? Das trägt einige Permissions ein, evlt. löst das schon das Problem.

Nein, das hilft leider nicht weiter...

js hat geschrieben:OpenJDK 1.6 funktioniert nicht.

Die Aussage kann ich so generell nicht bestätigen, da ja alles bis zum letzten Update von openJDK1.6 einwandfrei zu laufen schien und ich nun mit dem oben genannten Trick auch die Sim wieder zum Laufen bekomme... (auch wenn es wahrscheinlich sicherheitstechnisch ein Schritt zurück ist).
Das ihr die Version 6 nicht (mehr) offiziell unterstützt steht halt auf einem anderen Blatt. (Ich habe mich bisher nie drum gekümmert, welche Java/openJDK Version hier läuft, da ja bis gestern alles bestens funktioniert hat; getreu dem Spruch 'Never change a winning team')

js hat geschrieben:Da aber Java 6 ohnehin EOL hat, wird es da wohl auch keine Korrekturen mehr geben - weder von Java-Seite noch vom Sim. Vielmehr wird STS mittelfristig Java 7 voraussetzen.

Anfang Mai wird Mageia 3 released und dort wird dann eh openJDK 1.7 Standard sein. Auch für Mageia 2 wird eben aufgrund des EOL von Java 6 über einen Wechsel nachgedacht (die eigentliche upgrade policy bei Mageia ist halt, dass es innerhalb einer Mageia-Version keine großen Versionssprünge der angebotenen Software gibt, sondern nur die Sicherheitslücken gepatched werden).

Danke euch allen für die Tips und Hinweise

StellwerkSim

Fehler mit OpenJDK

Fehler mit OpenJDK

Re: Fehler mit OpenJDK

Re: Fehler mit OpenJDK

Re: Fehler mit OpenJDK

Re: Fehler mit OpenJDK

Re: Fehler mit OpenJDK