Error: Failed to install db46

Problemlösung hier gefunden: einfach das aktuelle Java Developer Update installieren (Hintergrund: db64 scheint beim Installieren eine bestimmte Datei zu erwarten, die eben nur noch im Developerpaket vorhanden ist).

Damit reiht sich nun ein weiterer Jupitermond in die Reihe der 3.x-Releases ein: besser, umfangreicher, aktueller.

Auf dem ersten Blick sieht Eclipse wie immer aus. Zwar wurde der Welcome-Screen, wie immer, in Punkto Design und Content geändert.. aber ansonsten ist alles wie gehabt.

Zwecks des kleinen Reviews habe ich die 64-Bit-Version (Cocoa) für Mac OS X heruntergeladen; da ich aber auch noch eine Reihe von Plugins benötige, diese dann später nachinstalliert. Prinzipiell hat sich der Updatemanager zumindestens optisch nicht zum Vorgänger geändert. Immerhin: Mit schätzungsweise 50 Einzelplugins ist der Installationsvorgang erstmalig in meiner persönlichen Eclipse-Geschichte problemlos von statten gegangen – sonst hat es immer irgendwo ein bisschen geknallt. Manchmal mit, meist ohne Auswirkungen. Unter anderem war auch ein SVN Connector Plugin dabei.

Es sieht so aus, als wäre in Eclipse kein VCS-Plugin (mehr) enthalten, vielmehr wird dies durch den Connector (ggf. bekannt aus 3.5) bekannt. Nach dem obligatorischen Neustart wird man sofort vom Connector-Wizard begrüßt und kann zwischen verschiedenen HavaHL und SVNKit-Versionen wählen. Ausgewählt, installiert, neugestartet. Fertig. Import, From SVN.. und voilá. Projekt ist drin. Interessant: Neuerdings wird man informiert, dass man gespeicherte Passwörter (SVN-Dialog) mittels Passphrasen absichern kann.

Die kleinen Details

"Eigenschaften" in Galileo

"Eigenschaften" in Helios

Ich habe mich im Vorfeld noch nicht mit den Änderungen und Neuerungen von Helios auseinandergesetzt, daher stochere ich etwas herum. Augenfällige Änderung: Die Eigenschaftsfenster einer Dateiressource wurden um eine detaillierte Rechte-Verwaltung erweitert.

Resources / Syncing

Aha… Resources können jetzt endlich gefiltert in einem Projekt eingefügt werden. Soll heißen: Man kann nicht nur weitere Resourcen dazu linken sondern auch explizit welche ausschließen. Yes!

Der Produktiveinsatz in den nächsten Wochen wird zeigen, was es sonst noch gibt.

Tatsächlich ist der WebApplicationContext eine Spezialisierung des oben genannten ApplicationContext — und zuständig für Webanwendungen. Da ein Servlet die Steuerung im Applicationserver übernimmt, benötigt der Spring-Context ein DispatcherServlet. Damit ist die “Verbindung” User->Server->Spring geschaffen. Soweit so gut.

Konfiguriert man das DispatcherServlet etwa – sinnigerweise – mit dem Namen”dispatcher”, dann sucht Spring standardgemäß nach einer dispatcher-servlet.xml. Diese XML-Konfigurationsdatei kann ähnlich der applicationContext.xml (u.ä.) ganz normale Bean-Konfigurationen enthalten. Interessant ist dabei, dass dabei ein zusätzlicher ServletContext erstellt wird. Das hat zwei Auswirkungen:

1. Beans aus dem ServletContext sind nicht im ApplicationContext verfügbar
2. Annotations-gestützte Konfigurationen müssen jeweilse in beiden Contexten konfiguriert, also aktiviert, werden

Hintergrund: Ist natürlich ein SQL-Schlüsselwort.