Verwendet man JDK 1.6 und JAX-RPC in der mit NetBeans ausgelieferten Version, so erhält man u.U. folgende Exception:
Exception in thread "main" java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.ver1_1.Message1_1Impl cannot be cast to com.sun.xml.messaging.saaj.soap.MessageImpl
at com.sun.xml.rpc.client.StubBase._postSendingHook(StubBase.java:231)
at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:324)
Die Ursache hierfür ist eine inkompatible SAAJ-Bibliothek. Nach dem Installieren der aktuellen Version von https://saaj.dev.java.net/ klappt es.
Donnerstag, 28. Februar 2008
Mittwoch, 23. Januar 2008
Java druckt nicht unter Ubuntu 7.10
Versucht man unter Ubuntu 7.10 aus einem Java-Programm etwas heraus zu drucken, so erhält man auf den meisten Systemen diese Exception:
java.lang.NullPointerException: null attribute
at sun.print.IPPPrintService.isAttributeValueSupported(IPPPrintService.java:1147)
at sun.print.ServiceDialog$OrientationPanel.updateInfo(ServiceDialog.java:2121)
at sun.print.ServiceDialog$PageSetupPanel.updateInfo(ServiceDialog.java:1263)
die Ursache hierfür ist die Drehbarkeit der Seite in CUPS v1.3. Hierbei wird beim Modus "automatisch" ein Nullpointer zurückgegeben, mit dem die aktuelle Java-Version noch nichts anfangen kann:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633656
Damit man trotzdem drucken kann, muss man entweder
deb http://de.archive.ubuntu.com/ubuntu/ feisty main restricted
Dann in der Datei /etc/apt/preferences - die ich neu erstellen musste - folgenden Eintrag machen:
Package: cupsys
Pin: version 1.2.8-*
Pin-Priority: 1001
Danach kann man mit
sudo apt-get update
sudo apt-get upgrade
die Version von CUPS auf die ältere deaktualisieren und das Drucken klappt wieder.
java.lang.NullPointerException: null attribute
at sun.print.IPPPrintService.isAttributeValueSupported(IPPPrintService.java:1147)
at sun.print.ServiceDialog$OrientationPanel.updateInfo(ServiceDialog.java:2121)
at sun.print.ServiceDialog$PageSetupPanel.updateInfo(ServiceDialog.java:1263)
die Ursache hierfür ist die Drehbarkeit der Seite in CUPS v1.3. Hierbei wird beim Modus "automatisch" ein Nullpointer zurückgegeben, mit dem die aktuelle Java-Version noch nichts anfangen kann:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633656
Damit man trotzdem drucken kann, muss man entweder
- die Seitendrehung von "automatisch" auf einen festen Wert stellen
- CUPS auf eine ältere Version umstellen
deb http://de.archive.ubuntu.com/ubuntu/ feisty main restricted
Dann in der Datei /etc/apt/preferences - die ich neu erstellen musste - folgenden Eintrag machen:
Package: cupsys
Pin: version 1.2.8-*
Pin-Priority: 1001
Danach kann man mit
sudo apt-get update
sudo apt-get upgrade
die Version von CUPS auf die ältere deaktualisieren und das Drucken klappt wieder.
Mittwoch, 7. November 2007
Sprache bei Ubuntu/Gutsy ändern
Ich sag's ja, wenn man Windows-Administratoren Linux-Maschinen installieren lässt: bei der Installation "Englisch" als Sprache ausgewählt! Klar, unter Windows macht man das so, damit man die Updates früher bekommt, bzw. damit Dritt-Software überhaupt funktioniert. Also die Sprache umstellen. Der altbekannte Weg
sudo dpkg-reconfigure localeconf
funktionierte unter Feisty, aber unter Gutsy nicht mehr. Hier muss man händisch die Datei
/etc/default/locale
Folgendes eintragen:
LANG="de_DE.UTF-8"
noch das Sprachpaket installieren:
sudo apt-get install language-pack-de
dann das altbewährte
sudo dpkg-reconfigure locales
und schon hat man nach einem Relogin alles auf Deutsch. Genauer beschrieben ist es hier:
http://wiki.ubuntuusers.de/Spracheinstellungen
sudo dpkg-reconfigure localeconf
funktionierte unter Feisty, aber unter Gutsy nicht mehr. Hier muss man händisch die Datei
/etc/default/locale
Folgendes eintragen:
LANG="de_DE.UTF-8"
noch das Sprachpaket installieren:
sudo apt-get install language-pack-de
dann das altbewährte
sudo dpkg-reconfigure locales
und schon hat man nach einem Relogin alles auf Deutsch. Genauer beschrieben ist es hier:
http://wiki.ubuntuusers.de/Spracheinstellungen
Donnerstag, 1. November 2007
nVidia Netzwerkkarten, Hibernate/Suspend und fehlende Netzwerkkonfiguration
Ich habe einen nVidia Corporation CK8S Ethernet Controller auf meinem Asus Board. Nach einem Suspend erhält die Karte keine IP-Adresse mehr. Den Grund dafür liefert ein dmesg:
0000:00:05.0: Invalid Mac address detected: 71:4a:28:d8:11:00
Please complain to your hardware vendor. Switching to a random MAC.
Bzw ein ifconfig, der nach jedem Suspend/Resume-Zyklus eine neue Netzwerkkarte (eth1, eth2 usw) anzeigt.
Aha: nach jedem Resume wechselt die MAC-Adresse, woraufhin mein Ubuntu von einer neuen Netzwerkkarte ausgeht. Ein Blick in /etc/udev/rules.d/70-persistent-net.rules zeigt auch das ganze Ausmaß der Katastrophe: viele Einträge mit unterschiedlichen MAC-Adressen. Laut einem Forums-Post handelt es sich hier um "reversed IP-address", was man im BIOS abstellen kann. Wer keine entsprechende Option findet, oder wie ich keine Lust hat, den Rechner neu zu starten, der stellt seine Netzwerkkonfiguration von MAC-Adresse auf PCI-Adresse um: die korrekte PCI-Adresse steht in der dmesg-Ausgabe; alternativ kann man auch die Ausgabe von lspci für die Netzwerkkarte verwenden und "0000:" davor schreiben (wer hat schon mehrere PCI-Busse installiert?). Dann passt man die Datei
/etc/udev/rules.d/70-persistent-net.rules
an, indem man den Eintrag
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:d8:28:4a:71", NAME="eth0"
durch
SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:00:05.0", NAME="eth0"
ersetzt, wobei natürlich die passende ID einzutragen ist. Danach klappt es dann auch mit dem Netzwerk nach einem Resume.
0000:00:05.0: Invalid Mac address detected: 71:4a:28:d8:11:00
Please complain to your hardware vendor. Switching to a random MAC.
Bzw ein ifconfig, der nach jedem Suspend/Resume-Zyklus eine neue Netzwerkkarte (eth1, eth2 usw) anzeigt.
Aha: nach jedem Resume wechselt die MAC-Adresse, woraufhin mein Ubuntu von einer neuen Netzwerkkarte ausgeht. Ein Blick in /etc/udev/rules.d/70-persistent-net.rules zeigt auch das ganze Ausmaß der Katastrophe: viele Einträge mit unterschiedlichen MAC-Adressen. Laut einem Forums-Post handelt es sich hier um "reversed IP-address", was man im BIOS abstellen kann. Wer keine entsprechende Option findet, oder wie ich keine Lust hat, den Rechner neu zu starten, der stellt seine Netzwerkkonfiguration von MAC-Adresse auf PCI-Adresse um: die korrekte PCI-Adresse steht in der dmesg-Ausgabe; alternativ kann man auch die Ausgabe von lspci für die Netzwerkkarte verwenden und "0000:" davor schreiben (wer hat schon mehrere PCI-Busse installiert?). Dann passt man die Datei
/etc/udev/rules.d/70-persistent-net.rules
an, indem man den Eintrag
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:d8:28:4a:71", NAME="eth0"
durch
SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:00:05.0", NAME="eth0"
ersetzt, wobei natürlich die passende ID einzutragen ist. Danach klappt es dann auch mit dem Netzwerk nach einem Resume.
Dienstag, 30. Oktober 2007
VirtualBox Shared Folder
Die VirtualBox ist eine gute Alternative zu VMware & Co, die zudem unter der GPL steht. Recht praktisch sind die "Shared Folder", mit denen man ein Verzeichnis des Gastgebes freigeben und vom Gast aus zugreifen kann. Realisiert ist das für Windows als CIFS-Freigabe. Leider bekommt man leicht eine Meldung in der Art "Fehler 67" Name nicht gefunden. Die Ursache hierfür ist sind fehlende oder falsch installierte Gasterweiterungen. Mir ist es passiert, dass ich eine Virtuelle Maschine unter Linux mit Version 1.5.0 installiert habe und dann unter MacOS X mit Version 1.4 nutzen wollte und eben diesen Fehler erhielt. Zur Lösung habe ich die Gasterweiterungen deinstalliert
net use x: \\vboxsvr\share
- mit "regedit" im magischen "Run"-Verzeichnis das Starten der Gasterweiterungen entfernt
- kurzfristig den Grafikkartentreiber umgestellt und beim obligatorischen Reboot dann die automatische Hardwareerkennung abgebrochen habe
- die Dateien aus C:\Programme und C:\Windows\System32 gelöscht (alles mit "innoprakt" und "vbox" im Namen)
net use x: \\vboxsvr\share
Auf JBoss von Außen zugreifen
JBoss lauscht von Hause aus auf der lokalen Adresse, spricht 127.0.0.1. Will man über das Netzwerk darauf zugreifen, muss man ihn mit
run.sh -b
starten, wobei man auch
run.sh -b 0.0.0.0
angeben kann, dann akzeptiert er Verbindungen auf allen Adressen. Auf meinem Ubuntu kam es aber dazu, dass der InvokerLocator noch auf 127.0.0.1:3873 lauschte, was sich so zeigt:
> netstat -ln | grep 3873
tcp 0 0 127.0.1.1:3873 0.0.0.0:* LISTEN
bzw. auf dem Client durch diese Exception:
org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://127.0.1.1:3873/]
Durch sehr genaues Hinschauen merkt man, dass dort 127.0.1.1 steht, was einen dazu bringt, man in der Datei /etc/hosts nachzusehen:
127.0.1.1 ubuntu
und da hat man den Schuldigen gefunden: JBoss bestimmt den Namen, unter dem er erreichbar zu sein glaubt und lauscht nur auf dieser Adresse. Trägt man hier die richtige eigene Adresse ein, am besten mit dem kompletten Namen, dann funktioniert es auch, also beispielsweise
192.168.1.31 ubuntu.local
run.sh -b
starten, wobei man auch
run.sh -b 0.0.0.0
angeben kann, dann akzeptiert er Verbindungen auf allen Adressen. Auf meinem Ubuntu kam es aber dazu, dass der InvokerLocator noch auf 127.0.0.1:3873 lauschte, was sich so zeigt:
> netstat -ln | grep 3873
tcp 0 0 127.0.1.1:3873 0.0.0.0:* LISTEN
bzw. auf dem Client durch diese Exception:
org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://127.0.1.1:3873/]
Durch sehr genaues Hinschauen merkt man, dass dort 127.0.1.1 steht, was einen dazu bringt, man in der Datei /etc/hosts nachzusehen:
127.0.1.1 ubuntu
und da hat man den Schuldigen gefunden: JBoss bestimmt den Namen, unter dem er erreichbar zu sein glaubt und lauscht nur auf dieser Adresse. Trägt man hier die richtige eigene Adresse ein, am besten mit dem kompletten Namen, dann funktioniert es auch, also beispielsweise
192.168.1.31 ubuntu.local
Montag, 22. Oktober 2007
JDK 1.3.1 unter Feisty/Gutsy
Installiert man das Sun JDK 1.3.1 unter Ubuntu/Feisty oder Gutsy, so erhält man beim Starten folgende Fehlermeldung:
/opt/jdk1.3.1_20/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
weil die entsprechende LibC nicht mehr unter diesem Namen verfügbar ist (das mit den unterschiedlichen inkompatiblen (G)LIBC-Versionen hab ich eh noch nie verstanden). Das Problem lässt sich glücklicherweise mit 3 Befehlen beheben:
sudo apt-get install libstdc++2.10-glibc2.2
cd /usr/lib
sudo ln -s libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2
Danach klappt es auch wieder mit dem Java:
/opt/jdk1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)
/opt/jdk1.3.1_20/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
weil die entsprechende LibC nicht mehr unter diesem Namen verfügbar ist (das mit den unterschiedlichen inkompatiblen (G)LIBC-Versionen hab ich eh noch nie verstanden). Das Problem lässt sich glücklicherweise mit 3 Befehlen beheben:
sudo apt-get install libstdc++2.10-glibc2.2
cd /usr/lib
sudo ln -s libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2
Danach klappt es auch wieder mit dem Java:
/opt/jdk1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)
Abonnieren
Posts (Atom)