Archiv der Kategorie Computer

Solaris

Heute habe ich eine 18 GB Festplatte, die ich letzte Woche bei EBay fuer 6,50 Euro ersteigert habe bekommen.

Sofort habe ich die in meine Sun Ultra 60 eingebaut und OpenSolaris 10 05/08 installiert. Das hat eine weile gedauert, aber versuch mal Windows Vista auf einem 10 Jahre alten PC zu installieren ….

Plan9 (aber nicht from outer Space) Teil 1

Ich bin ja so ein wenig ein Fan der Betriebssysteme mit dem x im Namen (mit zwei ausnahmen: bei Solaris ist kein x im Namen und Mac OS/X kenn ich nicht).

Seit einigen Jahren wird an den Bell Labs, das sind die Nachfolger jener bei welchen ursprünglich mal UNIX auf der PDP11 entwickelt wurde,  ein “Nachfolger” entwickelt. Der hat den Namen Plan9 angelehnt an den Legendären Science-Fiction Film”Plan 9 from outer Space” von Ed Wood. Das Konzept des “alles ist ein File” soll bei diesem Betriebssystem wirklich für alles gelten, z.B. auch für Netzwerkressourcen. Natürlich kann so ein neues Betriebssystem nicht ohne eine grafische Oberfläche daherkommen, deswegen wurde “rio” dazugebaut. Der “root”Benutzer heißt hier glenda, auch in Anlehnung an einen Ed Wood Film.

Hört sich alles ziemlich interessant an, oder? Also gut, gleich mal ausprobieren.

Da das ganze Open Source ist und von http://plan9.bell-labs.com/plan9/download.html heruntergeladen werden kann, stellt auch das kein Hindernis dar.

Also gedacht getan!

Da ich ja nun zwar schon so den einen oder anderen Rechner bei mir zuhause rumstehen habe, aber keinen nur für Plan9 reservieren wollte musst das ganze in einer Virtuellen Maschine laufen.

Als erstes habe ich mich an VirtualBox von Sun versucht. RPM Paket von https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=innotek-1.6-G-F@CDS-CDS_SMI für das entsprechende Host Betriebssystem herunterladen. Dann einfach das Paket installieren (in meinem Fall für Fedora Core 9):

rpm -ivh VirtualBox-1.6.2_31466_fedora9-1.i586.rpm

Jetzt kann mit dem erstellen der Virtuellen Maschine begonnen werden. Das erstellen, verwalten und ändern von virtuellen Maschinen geschieht mit dem Befehlt VBoxManage. VM anlegen:

VBoxManage createvm plan9

Noch eine virtuelle Platte mit 1 GB anlegen:

VBoxManage createvdi -filename plan9.dsk -size 1024

Diese “Platte” muss noch registriert werden:

VBoxManage registerimage disk plan9.dsk

Jetzt der VM noch ein wenig mehr Speicher gönnen

VBoxManage modifyvm -memory 512M

Und schon kann damit gearbeitet werden:

VBoxSDL -hda .VirtualBox/VDI/plan9.dsk -cdrom Download/plan9.iso -vm plan9

Damit startet die Virtuelle Maschine und bootet vom CD Image. Ach ich vergaß: damit ein Benutzer mit VirtualBox arbeiten kann muss er der Gruppe vboxusers angehören.

Auf diese Weise konnte ich plan9 installieren. Allerdings war das ganze ziemlich zäh und die “Load” anzeige die Plan9 bei der Installation zeigt hatte immer ca. 15.000 Interrupt anfragen. Ich habe ein wenig mit den Parametern der virtuellen Maschine rum gespielt, aber ohne erfolg.

Also zweiter Versuch mit qemu-kvm. Die Installation unter Fedora Core 9 ist ziemlich einfach:

yum install kvm

Damit hat man dann schon alles was man benötigt. Natürlich muss auch hier eine Image Datei für die virtuelle Platte erzeugt werden:

dd if=/dev/zero of=plan9.dsk bs=1024 count=1024000

damit bekommt man ein Image von (nicht ganz) 1GB. Gestartet wird die VM nun über:

qemu-kvm -cdrom Download/plan9.iso plan9.dsk -m 512

Und schon gehts los:
plan9_1.pngplan9_2.png

Die Installation kann beginnen. Diesmal gibts auch keine Probleme mit den Interrupts.

Nach der Installation und dem ersten Login (mit dem Benutzer glenda, das ist gewissermaßen der “root” Benutzer von plan9) sieht das ganze dann so aus.

plan9_3.png

So genug für heute. Fortsetzung folgt …

Ich bin nicht allein

Seit einiger Zeit arbeite ich an einem Projekt für einen Kunden. Dort wird die JPA mit der Implementierung Toplink Essentials verwendet.

Was mich das Ding Nerven gekostet hat!!!!!! Manchmal hab ich den Eindruck da sind mehr Fehler als funktionierende Features drin. So ein paar Highlights sind:

  • Die Umsetzung von EJBQL (oder JPQL) in SQL funktioniert nicht fehlerfrei. Wenn man es geschickt anstellt (so wie ich) baut er einen Select der ein kartesisches Produkt zurückliefert.
  • Laut Dokumentation lässt sich über einen Hint festlegen wie gecached werden soll. In einem Master Detail Modell funktioniert das aber immer nur für den Master…
  • Zumindest im OC4J kann ich nur einen persistence Provider verwenden. Das ist ja ganz prima, und was mache ich wenn ich Daten aus mehr als einer Datenbank benötige?
  • Das schreiben über merge funktioniert nicht zuverlässig. Ich hab wirklich an mir gezweifelt, aber es stimmt: Ab und zu vergisst der Toplink Essentials einfach Daten in die Datenbank zu schreiben. Obwohl ich ihm schon mit einem explizitem Merge gesagt habe er soll das tun! Mir war nicht möglich darin in irgendeiner Form einen Determinismus zu erkennen!
  • Und da kommt dann auch schon der nächste Bug: wenn der merge bei einem Detail Objekt einen Update machen soll dann “vergisst” er das auf jeden Fall!

So schön die JPA ist, mit Toplink Essentials kann man das nicht verwenden! Da ist man nur am Workaround bauen.

Ich habe schon einige sachen mit JPA und Hibernate gemacht. Der ist zwar jetzt auch nicht so ganz ohne, aber er hat (zumindest bei mir) immer ohne Probleme funktioniert.

Jetzt habe ich aber heute das hier auf diesem Blog entdeckt:

“For now I’ll keep using OpenJPA until the Glassfish people can make Toplink Essentials stop sucking so damn much. OpenJPA is a bit more pedantic anyway, and that’s a good thing. My code should end up tighter as a result”

Ich glaub ich muss mir mal OpenJPA angucken.

Web Services mit EJB 3.0 und JPA

Ich hab in letzter Zeit mal ein wenig mit durch EJB 3.0 implementierte SOAP Web Services rumgespielt. Alles in allem ist das prima, einfach ein paar Annotationen, und schon hat man einen Web Service.

Wenn man jetzt aber versucht seine JPA Klassen (die können ja serialisiert werden) über diesen Web Service zu schicken dann bekommt man (vorausgesetzt das Datenmodell besteht aus mehr als einer Klasse) die Fehlermeldung das “circular References” vorhanden sind.

Ist ja eigentlich auch klar. Die Java Klassen referenzieren sich ja mit “Zeigern” während im XML (dem SOAP Body) sowas natürlich nicht geht.

Die Frage ist nun ob man dem Container beibringen kann nur entweder die

@OneToMany

oder die

@ManyToOne

Methode zu serialisieren, und die jeweils andere zu ignorieren. Denn dann würds ja funktionieren. Vielleicht find ich da ja noch was …

Update Montag den 07. Juli 2008:
Also ich hab ganz schön lang gesucht und leider nix gefunden. Ich fürchte man kommt um DTO’s in diesem Zusammenhang nicht herum. Schade …

Update Sonntag den 04. Januar 2009:
Mann manchmal stellt man sich an! Ist doch ganz einfach, bevor man die Pojo’s als SOAP Nachricht verschickt löscht man in der EJB einfach die circular Reference raus. Voila, und schon gehts! Also nix mit DTO’s!!!!!

|