Nun also doch. Seit vorgestern bin ich glücklicher User von SHR-Unstable (Version vom 08.08.). Ich bin regelrecht begeistert, wie stabil und zuverlässig das System nach einigen Anpassungen läuft. Nur von opkg-cl upgrade sollte man die Finger lassen

Nach dem Einbinden der Jalimo-Repos installieren sich jetzt auch alle Java-VMs und die SWT- bzw. Java-DBus-Packages.

Wunderbar. Der Urlaub ist gerettet. Die Basteleien mögen beginnen

Die letzten Tage hatte ich etwas Zeit, mit Java und DBus auf meiner KDE-Kiste rumzuspielen. Da es jetzt unter Debian läuft, war mein nächster Versuch, es auf dem Neo Freerunner auszuprobieren. Da meine aktuelle OM2008.12-Distri leider noch nicht das DBus-basierte FSO-Framework verwendet, habe ich mir die Testing-Version von OM2009 auf die Speicherkarte installiert. Hier fängt auch schon die Leidensgeschichte an Nach einer halben Ewigkeit sieht man das sehr karge, eigentlich nur schwarz-weiße, User-Interface. Hier mal ein kleiner Screenshot:

Paroli Launcher

Mit Java siehts irgendwie düster aus. Es gibt zwar wieder die Standard-Packages in dem Testing-Repository, aber alles in Richtung DBus-Java, etc. fehlt. Hier kann man nur auf die Jalimo-Repositories ausweichen, welche aber leider veraltet sind und irgendeine Abhängigkeit auf eine nicht mehr vorhandene libgcc haben. Toll

Für heute mach ich mal Feierabend. In den nächsten Tagen wird das Image neu geflasht oder ein anderes verwendet. Vielleicht klappts ja dann. Folgender Thread hat mich doch etwas zuversichtlich gestimmt.

Hallo, jetzt habe ich schon einige Zeit nichts mehr hören lassen. Während ich nun den Klängen von Apocalyptica lausche gibts jetzt wieder eine feine Prise Java gemischt mit einem Hauch von Eclipse und das alles serviert auf einem frischen Neo Freerunner

1. Yoxos: Hier wollte ich noch etwas spielen, jedoch scheint der Dienst schon wieder Probleme mit der Verfügbarkeit zu haben
2. Java 1.5: Hier habe ich die JamVM ausprobiert, eine alternative VM zu Cacao. Allerdings hat JamVM die gleiche Schwäche wie Cacao, nämlich keinen Debug-Modus. Sollte mal ein Problem nur auf dem Zielgerät auftreten, guckt man als Entwickler in die Röhre, weil man nicht debuggen kann. Hier werde ich versuchen, mal die IBM J9 für ARM-Linux auszuprobieren. Mal schauen, wie diese VM sich unter Linux schlägt. Unter Windows Mobile hatte ich schon das Vergnügen. Hier sind es allerdings die vielen WinCE-Bugs, die einem den Spaß vermiesen können, aber das ist eine andere Geschichte
   Es ist außerdem ein bisschen Aufwand, die JamVM in Eclipse zu integrieren. Bei mir ging das zuerst dank der Erfahrungen mit Cacao ganz einfach, jedoch startet die JamVM bei mir grad aus unerfindlichen Gründen nicht mehr.
3. Equinox: Hier habe ich gemerkt, dass Equinox mit der JamVM ein bisschen schneller startet. Grob eine Sekunde eher als mit Cacao.
4. SWT: Hier gibts nix neues. Eclipse erlaubt mir nach wie vor nicht, eine zweite Java-GUI-Anwendung laufen zu lassen, die auf SWT zugreift. Der Fehler ist aber bekannt und ich muss das wohl hinnehmen
5. eRCP: Unverändert
6. ANT-Skripte, Deployment: Hier habe ich schon etwas herumexperimentiert. Zum Einen bietet das Freerunner die Möglichkeit, lokale Verzeichnisse mittels SFTP zu mounten. Die funktioniert ohne Probleme. Eine gute Lösung wäre, ein ANT-Skript zu erstellen, dass zuerst lokal ein Deployment-Verzeichnis erstellt und dieses dann mit dem Freerunner synchronisiert. Hier habei ich rsync als Sync-Tool ausgewählt. Probleme gibt es noch damit, dass auf dem Freerunner alle Dateien mit Root-Rechten versehen werden und der Client da manchmal nicht mitspielt.
   Zudem habe ich mir das Eclipse-Plugin Remote System Explorer (RSE) angeschaut, eine Sammlung von Tools zur Kommunikation mit anderen Rechnern. Zu diesen Tools gehören unter anderem ein SSH-Client für die Eclipse-Konsole, sowie die Möglichkeit, Filter für entfernte Verzeichnisse anzulegen. Eine Mount-Option habe ich noch nicht gefunden, es gibt allerdings die Funktion, ein entferntes Verzeichnis als Eclipse-Projekt einzubinden, was so ähnlich funktioniert.
7. Accelerometer: Hier versuche ich gerade die Datenstruktur zu verstehen. Das Auslesen der event-Dateien funktioniert ohne Probleme. Als nächstes werde ich das Tool netcat ausprobieren, mit dem ich die event-Dateien auf meinen Entwicklungsrechner holen könnte.
8. Anwendungs-Architektur: Ich habe mir schon einige Punkte überlegt, so soll es auf jeden Fall ein Plugin für die Accelerometer-Interpretation geben, sowie eines für die GUI. Logging der Daten wird noch optional mit eingebaut.
9. Anwendung: Ein bisschen Code existiert schon, ich bastle aber noch sehr viel dran rum.

Nach etwas Gebastel und Lesen von Mailing Listen habe ich nun SWT zum Laufen gebracht. Meine Meilensteine ändern sich nun wie folgend:

1. Yoxos: Ist nun wieder Online, ich habe aber Eclipse noch nicht richtig im Einsatz. Das kommt nun mehr ins Spiel.
2. Java 1.5: DONE, siehe http://hexor2k.wordpress.com/2008/12/27/erster-status/
3. Equinox: DONE, siehe http://hexor2k.wordpress.com/2008/12/27/erster-status/
4. SWT: Läuft nun, man muss folgende Punkte durchführen:
   1. Zuerst müssen die OPKG-Quellen so wie hier beschrieben angepasst werden. Die Pakete libswt3.4-gtk-java und libswt3.4-gtk-jni sollten installiert sein.
   2. Auf dem Buildrechner das SWT-Programm (ich hab das Beispiel von der Jalimo-Homepage verwendet) bauen mit folgendem Kommando: javac -cp /usr/share/java/swt.jar Sample1.java. Der Pfad und der Name von swt.jar kann je nach Distribution variieren, z.B. /usr/lib als Pfad oder swt-gtk.jar bzw. swt-gtk3.4.jar als Name.
   3. Das Programm muss nun auf den Zielrechner kopiert und mit folgendem Kommando gestartet werden: java -cp /usr/share/java/swt.jar:/usr/lib/jni:. Sample1. Auch hier können Pfade und Namen variieren, die von mir Gewählten gelten für das aktuelle FDOM Image. Der Startbefehl von der Jalimo-Homepage funktioniert nicht, da hier nur die swt.jar auf dem Classpath gesetzt wird und nicht das aktuelle Verzeichnis.
      Sollte man den Fehler „Exception in thread „main“ org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]“ erhalten so muss man noch „export DISPLAY=:0“ ausführen, dann geht es.
      Erhält man „Exception in thread „main“ java.lang.UnsatisfiedLinkError: no swt-gtk-3448 or swt-gtk in swt.library.path, java.library.path or the jar file„, so konnte die native SWT-Bibliothek nicht gefunden werden. Diese sollte eigentlich im Pfad /usr/lib/jni liegen. Ihr Name ist libswt-gtk-3448.so.
   4. Diesen Punkt möchte ich nun auch als DONE bezeichnen
      
5. eRCP: Unverändert, niedrige Priorität.
6. ANT-Skripte, Deployment: Nächster Punkt.
7. Accelerometer: Nicht begonnen.
8. Anwendungs-Architektur: Nicht begonnen.
9. Anwendung: Nicht begonnen.

Nachdem jetzt die Funktionalitäten getestet sind, werde ich mich nun auf Eclipse stürzen um diese auf die Openmoko-Entwicklung anzupassen. Dazu kommen jetzt auch die Skripte für Deployment ins Spiel.

Hier der aktuelle Status meiner Meilensteine für Java auf Openmoko:

1. Yoxos: Die Yoxos on Demand Homepage ist gerade down, alle Admins sind wahrscheinlich im Urlaub Ich habe mir glücklicherweise schon vor einigen Tagen eine eigene Eclipse per Yoxos erstellt und die nutze ich jetzt. Hier ist natürlich noch etwas Finetuning der Plugins notwendig.
2. Java 1.5: Das Hello-World-Programm läuft mit der Cacao VM und Java 1.5 Bytecode. Für Cacao habe ich ein Package in Debian Sid gefunden und installiert. In Eclipse kann man Cacao als Execution Environment einbinden, indem man eine neue Standard VM mit dem JRE-Home-Verzeichnis /usr/lib/jvm/cacao/jre/ erstellt. Das JRE des Java-Projekts muss auf Cacao geändert werden, ebenso die zugehörige Runconfiguration. Zusätzlich muss man bei der Runconfiguration noch die Umgebungsvariable java.library.path auf /usr/lib/jvm/cacao/jre/lib und die den darunterstehenden Radiobutton auf „Replace native environment with specified environment“ setzen, da ansonsten Eclipse den SUN-JRE-Classpath verwenden will, was zu der Fehlermeldung „main: lt_dlsym failed: /usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so: undefined symbol: vm_createjvm“ führt. Außerdem sollte man sich die JRE-Binaries genau ansehen, javah von Cacao wird in Debian auf das javah vom SUN-JRE gelinkt. Man sollte hier also nur java verwenden.
3. Equinox: Der Start von Equinox funktioniert ebenfalls, allerdings dauert es ziemlich lange, bis sich etwas tut. Ich habe darauf hin die OSGI-Implementierung von eRCP ausprobiert und voilá, in 10 Sekunden startet das Framework und der Logger. Ich werde deshalb für das weitere Vorgehen die eRCP-Bundles verwenden.
4. SWT: TODO. Die SWT-Anwendung von der Jalimo-Homepage funktioniert leider nicht. Ich glaube, ich steh hier grad aber auf dem Schlauch. Der Aufruf, wie er auf der Homepage beschrieben wird, sollte nach meinem Verständnis nicht funktionieren.
5. eRCPT: TODO. Native Java Bundles sollten funktioneren. Bundles mit eingebetteten DLLs oder SWT werden aber wahrscheinlich zu Fehlern führen.
6. ANT-Skripte, Deployment: TODO. Schon jetzt nervt das ewige Herumkopieren mit SCP. Wenn die Tests abgeschlossen sind, werde ich zuerst hier weiterarbeiten.
7. Accelerometer: TODO
   
8. Anwendungs-Architektur: TODO
9. Anwendung: TODO

Nachdem ich jetzt endgültig keine Lust mehr habe, weiter nach einem Service-Component Tracker zu forschen, hat das Neo Freerunner nun wieder meine Kreativität beflügelt Ich überlege gerade, welche Art von Funktion ich wohl auf dem Handy implementieren könnte.

Von der technischen Seite möchte ich nach folgenden Punkten forschen.

• Java als Programmiersprache, hier gilt es die Möglichkeiten der Cacao VM zu erforschen.
• OSGI als Komponentensystem. Eclipse Equinox ist ja 100% native Java, also sollte es auch laufen.
• SWT als GUI-Schnittstelle, hier gibt es bereits eine Implementierung namens Jalimo, die auf Cacao aufsetzt.
• eRCP als Plattform, wobei dies wahrscheinlich nicht möglich ist, da es eRCP anscheinend nur für Windoof Mobile gibt. Vielleicht funktioniert hier auch die normale RCP.
• DBus in Kombination mit Java auf dem Freerunner. Da es schon viele Applikationen mit  DBus-Interface auf dem Freerunner gibt, wäre interessant zu wissen, wie man mit Java darauf zugreifen kann.
• Eclipse als Entwicklungsumgebung. Die Zusammenstellung der benötigten Plugins erfolgt mittels Yoxos On Demand.
• ANT zum Bauen und Deployen auf dem Gerät, evtl. noch Start und Remote Debugging.

Als Programmidee schwebt mir vor, die Accelerometer des Freerunners auszulesen und die aktuelle Beschleunigung anhand von Balken anzuzeigen. Hier könnten dann gleich Echtzeitaspekte mit getestet werden.

Folgende Punkte möchte ich grob als Meilensteine festlegen:

1. Yoxos: Eine eigene Eclipse-Entwicklungsumgebung mittels Yoxos mit allen von mir benötigten Plugins zusammenstellen.
2. Java 1.5: Eine einfache Hello-World-Java-Applikation auf dem Freerunner laufen lassen.
3. Equinox: Eine einfache OSGi-Applikation erstellen und auf dem Freerunner laufen lassen.
4. SWT: Eine einfache SWT-GUI erstellen und auf dem Freerunner laufen lassen.
5. eRCP: Evtl. eine eRCP oder RCP basierte Anwendung erstellen und laufen lassen.
6. ANT-Skripte, Deployment: ANT-Skripte für Build und Deployment.
7. Accelerometer: Die Accelerometer unter Java auslesen, entweder File-basiert oder mittels Dbus.
8. Anwendungs-Architektur: Eine Architektur für die Anwendung festlegen.
9. Anwendung: Die Anwendung erstellen.

Zeitlich möchte ich mir keine Rahmenbedingungen setzen, da ich diese schon beim Service-Component-Tracker nicht einhalten konnte. It’s done when it is done

Da mir zwischen Arbeit, Fußball, Feuerwehr, Blogschreiben etc. immer noch genug Zeit bleibt, bin ich jetzt am Überlegen, ein kleines Open-Source-Projekt zu starten. Folgende Themen sollten darin vorkommen bzw. Technologien sollten genutzt werden:

• Java
• OSGi und Equinox
• Eclipse und RCP
• evtl. OpenGL (und wenns noch geht, Shader)
• evtl. EMF

Ich schwanke mittlerweile zwischen 3 Projekt-Zielen:

• DS-Tracker: Declarative Services sind leider im Equinox-Umfeld noch nicht so besonders integriert. Besonders mühsam ist die Fehlersuche, da oft nur das Log zur Verfügung steht. Ziel des Projekts sollte die Erstellung eines OSGi-Bundles sein, welches Kommandozeilenbefehle ähnlich zu den schon vorhandenen Befehlen zu Bundles, Services etc. bereitstellt, nur Ebene der Service-Komponenten. Damit sollen Service-Komponenten komfortabel abgefragt sowie gestartet und beendet werden können. Als Nebenschauplatz könnten noch Fehlermeldungen von der DS-Implementierung abgefangen und angezeigt werden können, da in manchen Fällen der Logger erst nach dem DS-Bundle startet. Das Projekt sollte eigentlich in kurzer Zeit zu schaffen sein und bietet nochmals einen guten Einstieg in DS und Equinox.
• 3D-Engine: Schon etwas ehrgeiziger, hier sollte die Entwicklung einer kleinen Rendering-Engine mittels RCP das Ziel sein. Wesentliche Bestandteile sollten sein, dass das Plug-in ohne Probleme in Eclipse integrierbar ist und dass sich neue Funktionalitäten mühelos einfügen lassen können (mittels Neuimplementierung vorgegebener Interfaces). Meine Idee wäre noch, 3D-Objekte durch ein EMF-Modell darzustellen und von der Engine interpretieren zu lassen. Ein 3D-Modell-Editor mit grafischer Anzeige könnte ebenfalls herausfallen.
• RCP-Desktop: Beim philosophieren über OSGI und RCP auf der Arbeit kam uns der Gedanke, dass ja OSGI und RCP quasi eine Art Betriebssystem für die JVM darstellen. In der Tat übernimmt RCP schon eine große Menge an Aufgaben wie z.B. File-Handling, Threading, GUI-Elemente … Unsere Idee war, aufbauend auf den vorhandenen Diensten eine Desktop-Shell zu erstellen welche komplett in RCP implementiert ist. Dies ist in ähnlicher Form nur durch das „Java Desktop System“ von Sun erhältlich, dieses baut jedoch meines Wissens nicht auf OSGI und RCP auf.
  Eine Idee war noch das Organisieren des Desktops nach Aufgaben, welche natürlich den Perspektiven aus RCP entsprechen. Beispiele wären eine File-System-Perspektive mit Views speziell für Dateisysteme, eine Development-Perspektive mit Entwicklungstools (Editor, Konsole, SVN …) oder eine Multimedia-Perspektive mit Media-Player, Meta-Daten-Browser …
  Das Projekt an sich ist natürlich sehr ehrgeizig und selbst mit einer kleinen Gruppe nur schwer vor dem 22. Jahrhundert zu schaffen sein, aber irgendwie geht mir die Idee nicht mehr aus dem Kopf.

So, nun sind die Ideen niedergeschrieben, wahrscheinlich werde ich mir erst mal über den DS-Tracker näher Gedanken machen, da ich eine solche Lösung auch akut auf der Arbeit brauchen könnte und sie sich auch in den Folgeprojekten gut bewähren könnte.

Jeder, der schon einmal selbst einen ANT Task geschrieben hat, kennt das Problem:

Man kann zwar ANT Scripts debuggen (innerhalb von Eclipse), in einen Task kann man aber nicht springen. Falls der Task wegen Fehlern abbricht, sieht man meist nur eine lapidare Fehlermeldung. Eine Hilfe wäre es zwar, Debugmeldungen via sysout auszugeben, schön ist das jedoch nicht.

Abhilfe schafft hier der Java Remote Debugger: Da ANT selbst eine Java-Anwendung ist, kann man diese im Debug-Modus starten. Zusätzlich meldet man diese Anwendung noch an einem Netzwerksocket als Remote Application an. Danach kann man von außen mittels einer eigenen Debugging-Instanz auf die Anwendung zugreifen und auf alle ihrer Breakpoints reagieren. Das folgende Beispiel bezieht sich auf die Eclipse IDE, mit anderen IDEs sollte es aber auch funktionieren.

So, nun das ganze mal als Code:

echo off
set ECLIPSE_HOME=""
set WORKSPACE=""
set PROJECT=""

%ECLIPSE_HOME%\eclipsec.exe -nosplash -data %WORKSPACE%
  -application org.eclipse.ant.core.antRunner
  -buildfile %WORKSPACE%\%PROJECT%\build.xml
  -vmargs -Xdebug -Xnoagent -Djava.compiler=NONE
  -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
echo on

ANT wird via Batch-File als Eclipse-Headless-Application gestartet und bekommt zusätzlich die Parameter für Remote Debugging angegeben (-Xrunjdwp:…). Dann erstellt man in Eclipse eine neue DebugConfiguration und wählt als Typ Remote Java Application. Weitere Parameter müssen nicht verändert werden. Nach dem Start der Batchfile erscheint eine Console mit den Ausgaben der ANT-Anwendung. Wenn nun die DebugConfiguration gestartet wird, hängt diese sich an den Remote Task an. Hat man nun in einem selbst geschriebenen ANT Task einen Breakpoint, so stoppt die Anwendung genau an diesem Punkt und wechselt in die Debug-Perspektive.

Nachdem ich auf der Arbeit ständig damit hantiere, gibts jetzt ne kleine Anleitung bzw. Checkliste für Declarative Services (DS) unter OSGI. Was sind DS? Ganz einfach: Normalerweise müsste man per Hand codieren, welche Services ein OSGI-Bundle anbietet und welche es verwendet. Dadurch entstehen einige Probleme, vor allem muss man sich selbst darum kümmern, was passieren soll, wenn ein Service mal nicht zur Verfügung steht oder sich im Betrieb verabschiedet. Außerdem ist es für einen Außenstehenden oft schwer einzusehen, welche Services das Bundle verwendet bzw. anbietet. Die Ressourcenbelegung ist auch ein Punkt, da die Services sich sofort bei Bundle-Start registrieren und nicht erst, wenn sie benötigt werden. Hier kommen die Declarativen Services ins Spiel. Mit ihnen kann man Services per XML-Datei konfigurieren.

Die folgende Checkliste wurde unter der Verwendung von Eclipse Equinox erstellt.

Checkliste: Was wird für Declarative Services benötigt?

• Die Implementierung der Deklarative Services erfolgt durch das Bundle org.eclipse.equinox.ds. Dieses Bundle muss immer mit geladen werden, bevor die DS verwendet werden können.
• Zusätzlich wird die Klasse ComponentContext aus dem Bundle org.osgi.service.component benötigt.
• Die eigentliche Implementierung des DS erfolgt als sog. Service Component, also einer Klasse, welche den Service (besser gesagt: das Service Interface) implementiert. Im Gegensatz zu einem Activator wird diese nicht abgeleitet oder implementiert eine Interface. Sie muss trotzdem folgende zwei Funktionen enthalten, damit die ServiceComponent funktioniert. Diese Funktionieren ähnlich wie die start und stop Methoden des Bundle-Activators.
  • protected void activate(Component context){…}
  • protected void deactivate(Component context){…}
    
• Eine Konfigurationsdatei in XML: Diese Datei wird üblicherweise in einem Verzeichnis namens OSGI-INF abgelegt, der Dateiname ist beliebig. Die XML-Datei selbst folgt dem hier zu findenden Schema. Wichtig ist hier, dass alle Inhalte der XML-Datei, also Tags, Attribute aber Paket- und Klassennamen richtig geschrieben sind, ansonsten kann die Service Component nicht aktiviert werden.

• Änderung im Manifest-File des Bundles: Füge eine neue Zeile hinzu, der Inhalt ist Service-Component: OSGI-INF/service.xml (wenn die XML-Datei service.xml heißt)

Beispiel:

Hierzu ein kleines Beispiel: Eine ServiceComponent soll erstellt werden, die einen Service mit dem Interface MyServiceInterface bereitstellt. Sie soll außerdem eine Liste von Services des Interface OtherService beinhalten. Dazu bindet sie diesen Service (der auch über eine Service Component realisiert werden muss) mit der cardinality=“1..n“, so dass mindestens ein OtherService vorhanden sein muss, um die Service Component zu aktivieren. Die einzige Funktion in MyServiceInterface gibt die Anzahl der angebundenen OtherService zurück.

Service Interface:

package org.example.ds
import ...
public interface MyServiceInterface {
    int getCount();
}

Implementierungs-Klasse:

package org.example.ds.internal
import ...
public class MyServiceImplementation implements MyServiceInterface {

    private ComponentContext context;
    private List<OtherService> servicelist = new Vector<OtherService>(0);

    protected void activate(ComponentContext context){
        this.context = context;
    }

    protected void deactivate(ComponentContext context){
        this.context = null;
    }

    protected void bindOtherService(OtherService otherservice){
        this.servicelist.add(otherservice)
    }

    protected void unbindOtherService(OtherService otherservice){
        this.servicelist.remove(otherservice)
    }

    public int getCount(){
        return this.servicelist.size();
    }
}

Die XML-Datei im OSGI-INF Ordner:

<?xml version="1.0" encoding="UTF-8"?>
<component name="myServiceComponent">
    <implementation class="org.example.ds.MyServiceImplementation"/>
    <service>
        <provide interface="org.example.ds.MyServiceInterface"/>
    </service>
    <reference
        name="otherservice"
        interface="org.example.ds.OtherService"
        bind="bindOtherService"
        unbind="unbindOtherService"
        cardinality="1..n"
        policy="static"
    />
</component>

Fehlersuche:

• Das Bundle startet, aber die Service Component nicht. Dies kann viele Ursachen haben:
  • Schreibfehler in der Manifest- oder XML-File. Am besten nochmal nachschauen, ob alle Paket- und Klassennamen stimmen.
  • Eine geforderte Referenz ist nicht verfügbar. Untersuche alle Referenzen, ob deren Service Components vollständig gestartet wurden.
  • Eintrag in der Manifest-File fehlt oder ist ungültig. Mein absoluter Lieblings-Fehler
  • Funktionen wie activate/deactivate bzw. bind/unbind fehlen oder sind ungültig.
• NullPointerException oder andere krude Exceptions werden geworfen: Dies kann auftreten, wenn Klassenmember in der activate-Funtion belegt werden. Diese wird nämlich erst dann aufgerufen, wenn alle Referenzen erfüllt sind, also erst nach den bind-Funktionen. Wenn in bind schon auf das Member zugegriffen wird, ist es dann noch null und die NullPointerException wird geworfen.
• Hilfe, ich sehe nicht ob sich irgendwas tut!!!
  • Der Status einer Service Component kann leider nicht einfach über den status-Befehl abgefragt werden, da Service Components ein relativ neues Konzept sind.
  • Eine Service Component meldet ihre Services sofort an der Service Registry an, der Befehl services gibt also keinerlei Aufschluss über den Status ser Service Component.
  • Am besten kann der Lebenszyklus über den Log-Service verfolgt werden, den Equinox mitliefert. Er kann über das Bundle org.eclipse.equinox.log angebunden werden