Eclipse RCP / OSGI und Projekt-Konzept

antimon

Mitglied
Hallo zusammen,

ich habe ein paar Verständnisprobleme bezüglich der modularen Programmierung mit Eclipse RCP, vielleicht könnt Ihr mir helfen, diese zu beseitigen.

Mein Ziel ist es, mit Eclipse RCP ein Programm zu erstellen, mit dem man Projekte öffnen, bearbeiten und speichern kann. Das Programm besteht aus mehreren Modulen, die alle auf die Projektdatei zugreifen können sollen. Im Modul "core" wird das eigentliche Projekt gemanagt, also die Datei zum Bearbeiten geöffnet, gespeichert etc.

Angenommen das Programm ist gestartet, ohne dass ein Projekt geöffnet wurde. Irgendwann öffnet ein Benutzer ein Projekt, das sollten alle Module mitbekommen - also registrieren sie sich beim Modul "core", das für das Projektmanagement zuständig ist als Listener und bekommen dann den Öffnungsvorgang mit - ist das so richtig?

Was ist nun, wenn beim Programmstart das zuletzt geöffnete Projekt automatisch geladen werden soll? Würde es dann Sinn machen, wenn alle Module initialisiert wurden und sich als Listener registriert haben, den gleichen Vorgang durchzuführen, wie wenn ein Benutzer ein Projekt öffnet, nur eben automatisch und programmgesteuert? Oder ist es besser, wenn alle Module beim Initialisieren schauen ob das Projekt schon offen ist und dann gleich die benötigten Daten laden?
Wie wäre es im ersteren Fall - wie bekomme ich mit dass alle Module geladen und bereit sind (also sich als Listener registriert haben)?

Und laut OSGI-Konzept ist jedes Modul zu jeder Zeit beendbar... wenn nun das Modul "core" beendet wird, hängen quasi alle Module, die aufs Projekt zugreifen wollen, "in der Luft" - wie managt man sowas?

Vielen Dank für Eure Bemühungen!
 
Mein Vorschlag hier wäre dazu folgender:

- Du schreibst dir eine Funktion die immer aufgerufen wird, wenn ein Projekt geöffnet wird, also egal ob vom Benutzer oder vom Programm selbst. Diese Funktion ist dafür zuständig alle Module zu verständigen die diese Aktion mitbekommen sollen

so hast du nur einmal die Arbeit dir gedanken zu machen was jetzt wo benachrichtigt ist ;)

zu deinem zweiten Problem:
ich habe mich zwar noch nicht direkt mit OSGI aber mit Modularisierung an sich beschäftigt. Es ist bei dem Beenden eines Moduls wichtig zu überprüfen ob das zu schließende Modul noch offene Unter-Module hat, die ohne das Modul keinen Sinn mehr machen. Diese sollten dann ebenfalls geschlossen werden um unnötige Speicherbelastung zu vermeiden.
Eine Möglichkeit wäre das auch per Listener zu lösen so dass das Modul einfach alle Untermodule benachrichtigt, dass es jetzt geschlossen wird. Dadurch können alle Untermodule noch Schritte ausführen bevor sie auch geschlossen/beendet werden

Ich hoffe das beantwortet im Großen und Ganzen deine Fragen
 
Hallo Tsunamii,

danke schon mal für deine Antwort. Prinzipiell hast du natürlich Recht, allerdings glaube ich, habe ich nicht genau genug gesagt, was ich meine. Angenommen, es gibt genau eine Methode, die für das Laden zuständig ist - wann wird diese aufgerufen? Wenn man es eben während der Initialisierung aufruft, kann es sein, dass ein anderes Modul noch nicht initialisiert ist, welches aber benötigt wird. Wenn der User ein Projekt öffnet, kann ich davon ausgehen, dass alles bereits geladen ist. Während des Initialisierens selbst aber weiss ich das noch nicht - deswegen wärs evtl. praktisch ein Öffnen eines Projekts erst dann zu starten, wenn der Rest bereit ist - nur wie stelle ich fest wann das soweit ist?

Bezüglich OSGI - leider steckt da der Teufel im Detail. Denn wenn du Module und Unter-Module hast, wie du sagst, kannst du die beenden und per Listener benachrichtigen. Aber bei OSGI ist das Konzept so, dass ein Modul die anderen prinzipiell nicht kennt - es bietet Schnittstellen und kann die Schnittstellen anderer Module verwenden - welches Modul die Schnittstelle implementiert, sollte aber in der Regel egal sein (falls ich das falsch verstanden habe, bitte korrigieren!).
Das heisst also, ich sollte den Core beispielsweise herunterfahren können, um ihn live auszutauschen, z.B. durch eine neuere Version.
Bei Eclipse kannst du das ja tun, wenn neue Updates eingespielt wird, auch wenn empfohlen wird, neu zu starten.
Vielleicht könnte man ja die Einschränkung machen, dass nach Updates immer neu gestartet werden muss - was die Handhabung denke ich wesentlich vereinfachen würde, weil man nicht so viel berücksichtigen muss. Aber da ich da noch keine Erfahrungen habe, wollte ich mal hören, wie andere das so machen, bzw. obs irgendwelche Empfehlungen gibt. Denn Tutorials, wie man Module programmiert etc. gibts zuhauf - aber wenns in den fortgeschritteneren Bereich geht, werden die Tutorials eher rar... :-/
 
Bezüglich OSGI - leider steckt da der Teufel im Detail. Denn wenn du Module und Unter-Module hast, wie du sagst, kannst du die beenden und per Listener benachrichtigen. Aber bei OSGI ist das Konzept so, dass ein Modul die anderen prinzipiell nicht kennt - es bietet Schnittstellen und kann die Schnittstellen anderer Module verwenden - welches Modul die Schnittstelle implementiert, sollte aber in der Regel egal sein (falls ich das falsch verstanden habe, bitte korrigieren!).
Das mit den Schnittstellen ist mir bewusst. Das Programm an dem ich momentan arbeite besitzt auch ein Hauptmodul das alles steuert und eingehende Nachrichten weiterleitet. Daneben gibt es dann noch einzelne Komponenten, die aber wiederum einzelne Unter-Module haben. Das ganze natürlich so, dass man einfach Module austauschen kann und das Programm immernoch funktioniert.

Gelöst habe ich das ganze mit einem ModulInterface, dass genau 3 Funktionen bereitstellt:
- starteModul(ModulKontext pKontext)
- beendeModul()
- eventNotify(MyEvent pEvent)

der Kontext der zu Anfang mitgegeben wird enthält alle nötigen Infos die das Modul benötigt um selbstständig arbeiten zu können.
und das eventNotify dient dazu geziehlt Unter-Module anzusprechen, falls dies nötig bzw. möglich ist (bei mir habe ich z.B. immer eine aktive Komponente mit einem aktiven Modul, die jeweils der nächst höheren Instanz bekannt sind)
für allgemeine Notifies kann man ja die Module beim starten einfach an einen EventService anbinden sodass diese Nachrichten schicken und empfangen können
 
Hallo antimon,

um rich Architektur der Rich Client Platform besser verstehen zu können (darunter fällt auch OSGi oder Equinox), empfehle ich dir die Rich Client Platform Architektur zu studieren. In diesem Artikel wird zusätzlich noch auf SWT, JFace oder die grafische Oberfläche eingegangen.
 
Hallo z-mon,

danke für den Link, der prinzipielle Aufbau ist mir allerdings schon klar, ich habe mich natürlich erst in alle möglichen Tutorials eingelesen. Es handelt sich bei meinen Problemen eher um speziellere Dinge.

Beispiel:
Ein Bundle erweitert meine Anwendung um die Möglichkeit, auf eine Schnittstelle zuzugreifen - es implementiert ein Interface zum Öffnen und Schließen der Schnittstelle und zum Senden von Daten.
Beim Empfangen von Daten wird es schon wieder interessant: Ist es sinnvoll, dass das Modul selbst eine (bekannte) Methode in "der Anwendung" aufruft oder muss/soll im Interface eine Methode definiert werden, bei der sich "die Anwendung" als Listener registrieren kann, um empfangene Daten zu bekommen?
Und prinzipiell sollten laut OSGI ja beide Module, also "die Anwendung" sowie das Bundle der Schnittstelle jederzeit beendet, aktualisiert und neu gestartet werden können. Doch wie macht man das, damit beide Seiten damit klarkommen? Denn normal ist ja zuerst "die Anwendung" und dann kommt die Erweiterung, aber umgekehrt müsste das ja auch funktionieren...?
 
Zurück