Ereignisse beim Start der Anwendung

Nach dem Start wird zunächst geprüft, ob eine alte Version vorhanden ist. Dazu gibt es im ConfigurationManager die Methode checkFirstStart. Hier werden zunächst die Aufrufparameter geprüft. Folgende Parameter sind möglich:

• --workspace Auswahl des Workspace

Ob die Anwendung das erste Mal gestartet wird, wird anhand der Preference PersistenceUnitProperties.JDBC_DRIVER festgestellt. Ist diese nicht vorhanden, kann man davon ausgehen, daß es der erste Start ist. Das bedeutet, daß der Workspace zunächst selektiert werden muß. Anschließend erfolgt ein Neustart, wobei vorher in den Preferences die Einstellung GENERAL_WORKSPACE_REQUEST gesetzt wird, um beim Neustarten sofort in den entsprechenden Modus wechseln zu können. Der Neustart wird in der Klasse InitialStartupDialog ausgelöst, nachdem der neue Workspace selektiert wurde. Dieser Dialog beinhaltet auch die Selektionsmöglichkeit für die Datenbank-Verbindung. Sollte in dem angegebenen Workspace eine alte Version gefunden werden, wird die Migration initiiert (der Auslöser dazu ist die Voreinstellung ConfigurationManager.MIGRATE_OLD_DATA).

Beim Starten läuft folgendes ab:

• Aufruf des Activators (com.sebulli.fakturama.Activator). Hier werden einige grundlegende Initialisierungen vorgenommen (Icons usw.)
• Danach kommt der com.sebulli.fakturama.LifecycleManager zum Zuge. Als Einstiegspunkt wurde @ProcessAdditions gewählt, weil man dann bereits auf Elemente des Modells zugreifen kann, was sich beim Benutzen diverser Dialoge einfacher macht. Hier wird zunächst geprüft, ob in den Preferences ein JDBC-Eintrag für die Datenbank existiert. Da das eine ziemlich grundlegende Einstellung ist, die bei einer Neuinstallation definitiv nicht da ist, kann davon ausgegangen werden, daß es hier um eine solche geht. Ist kein Eintrag vorhanden, wird ein Event-Handler registriert (AppStartupCompleteEventHandler), der dafür sorgt, daß beim Hochfahren der Anwendung unmittelbar nach dem Initialisieren der Workbench die ganze Anwendung nochmal gestartet wird. Das hat den Grund, daß beim Auswählen der ganzen Einstellungen (JDBC-Zugangsdaten usw.) eigentlich unmittelbar ein Neustart folgen müßte. Das geht aber nicht, weil es noch keine Workbench gibt, an der man die Methode restart() aufrufen könnte. Deswegen ist das hier eine Art „Merker“ für die Neu-Initialisierung.
  Falls ein Eintrag vorhanden ist (und somit die Anwendung zumindest in einem Stadium ist, in der eine DB konfiguriert wurde), wird ein DAO aufgerufen. Das wurde deshalb gemacht, weil das Initialisieren dieser DAOs sehr lange dauert. Mit dieser Variante besteht die Möglichkeit, daß der User gleich nach dem Start der Anwendung weiterarbeiten kann, ohne erst auf die Initialisierung warten zu müssen (die anderen DAOs benötigen nicht so lange, weil die Erst-Initialisierung ja bereits durchgeführt wurde).
• Nach dem Installieren des Handlers wird der com.sebulli.fakturama.startup.ConfigurationManager aufgerufen. Hier wird dann vorsichtshalber nochmal geprüft, ob die Einstellung für JDBC existiert. Wenn nicht, wird der Dialog zur Selektion eines neuen Workspace sowie für die JDBC-Einstellungen angezeigt (com.sebulli.fakturama.startup.InitialStartupDialog).
• im InitialStartupDialog werden die ganzen Zugangsdaten für die DB abgefragt und auch das alte und neue Arbeitsverzeichnis. Das hat den Hintergrund, daß evtl. Altdaten migriert werden müssen. Eine entsprechende Abfrage erscheint jeweils nach dem Verlassen des Feldes.
  Bei den Datenbank-Einträgen gibt es momentan jeweils zwei Einträge für die unterschiedlichen Derby-Varianten. Das muß noch korrigiert werden (das eine ist in-memory, das andere persistent). Es werden alle Datenbanken angezeigt, die als (OSGi-)Bundle gefunden wurden. Das ist beispielsweise wichtig, wenn man versucht, eine neue Datenbank einzurichten / anzubinden. Dazu muß man zunächst den Treiber in ein OSGi-Bundle verwandeln (falls es den noch nicht gibt). Im Eclipse Gemini-Projekt sind bereits einige Treiber konvertiert worden.
• Nachdem alle Daten eingegeben wurden, wird die Anwendung kurz fertig initialisiert und dann neu gestartet. Vorher kommt noch ein entsprechender Info-Dialog.
• Welcher (alte) Workspace konvertiert werden soll, steht in ConfigurationManager.GENERAL_WORKSPACE_REQUEST. Diese Einstellung wird (temporär) in den Preferences gespeichert und wird im ConfigurationManager im zweiten Durchlauf ausgelesen. Hier wird dann auch der eigentliche Workspace in den Einstellungen persistiert. Falls Altdaten migriert werden sollen, wird das an dieser Stelle angeschoben.
  Die Mechanik Handler/Command kann hier nicht verwendet werden, da diese in dieser frühen Phase der Anwendung noch nicht zur Verfügung stehen. Das geht auch mit „künstlicher“ Injection (via ContextInjectionFactory.make()) nicht.

• Beim Migrieren der alten Daten wird die komplette Alt-Datenbank durchgegangen und es werden alle nicht-gelöschten Entitäten konvertiert.

  Wichtig ist auch, auf den richtigen Aufbau der JDBC-URL zu achten, sonst verabschiedet sich die Anwendung gleich beim Klick auf die erste View.

  Konkret sieht eine Preferences-Datei (unter Windows) so aus, wenn eine Migration ansteht (siehe {product.path}.metadata.pluginsorg.eclipse.core.runtime.settingscom.sebulli.fakturama.rcp.prefs):

  GENERAL_WORKSPACE_REQUEST=pathtoFakt2 MIGRATE_OLD_DATA=pathtoFakt1.6.1 OLD_JDBC_URL=jdbc:hsqldb:hsql://localhost/Fakturama eclipse.preferences.version=1 javax.persistence.jdbc.driver=com.mysql.jdbc.Driver javax.persistence.jdbc.password=xxx javax.persistence.jdbc.url=jdbc:mysql://localhost/fakturama javax.persistence.jdbc.user=xxx jdbc_reconnect=true