OSGi Problem beim Verwenden von Declaratice Services

[dzim]

Hallo zusammen,

ich habe letzte Woche versucht einige der etwas "kruden" Datenanbindungen durch OSGi Declaratice Services abzulösen, bin dabei aber auf ein Problem gestoßen:
Wenn ich in meiner RCP-Application die Abhängigkeiten zu org.eclipse.osgi.services, org.eclipse.equinox.ds und org.eclipse.equinox.util hinzufüge, stürzt mir die Anwendung ohne weitere Meldung, ohne Log-Eintrag oder sonst etwas hab. Nach ein wenig Debuggen fand ich heraus, dass irgendetwas auf einmal anscheinend probierte, ein "Multi-Display" anzulegen, was anscheinend einen SWTError produzierte.

Zum System und Service:
Ich verwende Ubuntu 11.10 64Bit - vielleicht hat der eine oder andere ja mal was von einem SWT-Bug oder so gehört...
Den Service hatte ich mir folgendermaßen vorgestellt und bisher implementiert: Meine RCP-Anwendung (eine Plugin-basiert Plattform) stellt das Service-Interface zur Verfügung und exportiert das entsprechende Package. Ein weiteres Plugin (oder besser Bundle) implementiert den Service und bietet ihn als DS (über OSGI-INF/component.xml) an. Meine Platform selbst wiederum soll (so war der Plan) auch wieder der Consumer sein und hat dementsprechend auch eine Komponentendefinition (über OSGI-INF/component.xml).

DS-Komponente
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="x.y.z.ds.services">
<implementation
class="x.y.z.ds.services.Services"/>
<service>
<provide
interface="x.y.z.service.IAvailablePluginService"/>
</service>
</scr:component>
[/XML]

Plattform-/Consumer-Komponente
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="x.y.z.service.consumer">
<implementation
class="x.y.z.service.consumer.GlobalServiceConsumer"/>
<reference
bind="setAvailablePlugins"
cardinality="0..n"
interface="x.y.z.service.IAvailablePluginService"
name="IAvailablePluginService"
policy="dynamic"
unbind="unsetAvailablePlugins"/>
</scr:component>
[/XML]

Ich habe mich versucht an das Tutorial von Lars Vogel zu halten. Ich denke die meisten wissen, was ich meine, daher keine Verlinkung...
Wenn ich die Dependencies in meine Platform und meine Runtime Configuration eintrage, bricht das Program beim Start (nachdem kurz einmal der Splash-Screen auftauchte) ab.

Beim Debuggen, habe ich einen Breakpoint direkt auf dem Versuch das Display zu erstellen gelegt und erreiche nicht einmal den Punkt des erstellens der Shell für das Splash - alles etwas seltsam...

	public Object start(IApplicationContext context) throws Exception {

		Display display = PlatformUI.createDisplay();
		try {

			// look and see if there's a splash shell we can parent off of
			Shell shell = WorkbenchPlugin.getSplashShell(display);
			if (shell != null) {
				// should should set the icon and message for this shell to be
				// the same as the chooser dialog - this will be the guy that
				// lives in the task bar and without these calls you'd have the
				// default icon with no message.
				shell.setText(OpenWorkpaceDialog.WINDOW_TITLE);

				ImageDescriptor imgDescr = Activator
						.getImageDescriptor("icons/logo_16.gif"); //$NON-NLS-1$
				if (imgDescr != null)
					shell.setImage(imgDescr.createImage());
				else
					shell.setImages(Dialog.getDefaultImages());
			}
[...]

Hier noch einmal der Fehler (den ich nur im Debugmodus auf der Konsole des Eclipse erhalte):

The program 'SWT' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadGC (invalid GC parameter)'.
  (Details: serial 734 error_code 13 request_code 60 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

... und wie ich gerade feststelle, ist es wieder einmal ein anderer Fehler - das scheint sich auch nach Tageslaune zu ändern ...

Wenn ihr hinsichtlich der DS Hinweise allgemeiner Natur habt, oder bezüglich des Set-Ups, oder auch des Fehlers, wäre ich sehr Dankbar!

Viele Grüße,
Daniel

[edit]
Ach so: Ich verwende Eclipse 3.7
[/edit]

[edit]
2ter Nachtrag:
Ich hatte beim ersten Versuch ('BadGC [...]') noch nicht alle Dependencies in der Runtime Config aufgelöst. Nach betätigen des "Add Required Plugins"-Knopfes kommt nun das hier:

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
java: ../../src/xcb_io.c:178: dequeue_pending_request: Zusicherung »!xcb_xlib_unknown_req_in_deq« nicht erfüllt.

[/edit]

 

[maki]

Das sieht nicht nach einem DS Fehler sondern nach einem OS bzw. SWT Fehler aus.

Schon mal mit einer 32 Bit Version probiert?

 

[dzim]

Du meinst sicher vom SWT-Bundle, oder?
Hab es gerade mal versucht, aber mit eher weniger Erfolg. (SWTError...).

Könnte höchstens mal zu Testzwecken Eclipse 3.7.1 installieren und es damit mal probieren, aber ich hab wirklich derartig viele Projekte im Workspace und noch andere Abhängigkeiten (wie etwas das Delta-Pack) drin, dass es dann sicher wieder an andere Stelle kracht...

 

[maki]

Laut den Fehlern in deinen Nachträgen ist es ein SWT bzw. WindowManager Problem.

Hast du ein 64 Bit Windows zum testen was da passiert?

 

[dzim]

Naja, ich könnte mir mal eine VM installieren und es da testen, sonst aber direkt nicht...
Ich könnte es höchstens mal exportieren und nem anderen Kollegen schicken, dass er es mal probiert.
Ich versteh nur nicht, warum dass erst passiert, wenn ich die Dependencies hinzufüge. Ich meine, was hat DS denn bitte damit zu tun, dass hier ein weiteres Display benötigt wird?

 

[maki]

Denke dass ist nur ein Seiteneffekt, ohne DS kommen früher andere Fehler, mit DS treten später andere Fehler auf weil er weiter kommt als ohne

 

[dzim]

So. Hab es erst mal mit nem Eclipse 3.7.1 probiert. Gleiches Ergebnis... Meine VM installiert gerade noch, also mal abwarten, wie es dann dort läuft.
Auch wenn mir gerade einfällt, dass es wieder ein 64Bit System ist. Mist. Und ich hab die Target Platform noch mit dem 3.7er Babelpack drin gehabt, wer weiß, was das für einen Einfluss hat.
Aber ich probier es dann wahrscheinlich auch mal mit Precise und Eclipse 3.7.1 - mal sehen, was so passiert...

 

[dzim]

Eclipse 3.7.1/4.2M4 auf einer VM (wie gesagt, 64Bit-System) produziert das selbe negative Ergebnis.

Könnte es vielleicht auch sein, dass hier noch andere Dependencies nicht aufgelöst sind, die nur nicht richtig angezeigt werden? Beim Portieren von 3.x-Anwendungen auf 4.x gab es da ja auch mitunter Probleme...

Eine andere Idee ist: Ich habe die bisherigen Dep. im Manifest hinterlegt und in die Runtime Config eingetragen, diese aber beruht auf einem .product - dort habe ich die Dep. noch nicht eingetragen. Ob das auch Probleme machen kann?

 

[dzim]

Ich habe nun das Service-Interface sowie den Consumer aus der Anwendung herausgelöst und die Implementieren des DS angepasst, damit ich das Ganze mal auf der OSGi-Konsole testen kann, habe hierzu noch die beiden Klassen um die Methoden protected void activate(ComponentContext componentContext) und protected void deactivate(ComponentContext componentContext) hinzugefügt. Immerhin sehe ich, dass sie de-/aktiviert werden, wie erhofft. Jetzt muss sich der Sch*** "nur" noch in die RCP-Anwendung integrieren lassen...

 

[maki]

Das DS funktioniert hätte ich dir auch sagen können

Wie gesagt, denke der Fehler steckt woanders, speziell in einer SWT bzw. Plattformabhängigen Lib, deswegen der Tipp mit einem anderen OS oder anderen Architektur zu testen.

 

[dzim]

Ok, ein weiteres Update: Mittels der heute vorgenommenen Kapselung der Services in nun zwei separate Projekte, kann ich nun auch in meiner Applikation die notwendigen Dependecies einfügen, ohne dass die Anwendung noch beim "hochfahren" des SWT bereits abstürzt. Das ist immerhin schon einmal ein großer Schritt in die richtige Richtung!

Aber: Ihn wirklich verwenden kann ich noch nicht und ich denke hier hab ich ein grundsätzliches Verständnissproblem, wie man Services allgemein und DS speziell überhaupt benutzt.
Ein Kollege von mir hat in dem Projekt, an dem er mitarbeitet, IPOJO verwendet - da ich die Wahl der Qual hatte, habe ich mich dagegenentschieden und wollte in der Welt bleiben, in der ich mich sowieso durch die RCP-Anwendung bewege - also Equinox, daher auch DS. Jedenfalls bekommt er seine Services ja via irgendeiner Dependecy Injection über Annotationen dorthin gereicht, wo er sie benötigt. Ich allerdings weiß gerade nicht, wie ich denn nun tatsächlich eine Instanz meines Service Interfaces bekomme.
Das OSGi Buch, welches ich hier verwende, ist da leider gerade keine Hilfe. Ich seh jedenfalls gerade nicht, wie ich z.B. in einem View nun den Service referenziere. Ich bin mir sicher, dass da irgendwie der Name, den ich der Komponente gegeben habe (auf beiden seiten der gleiche Name?) eine wichtige Rolle spielt...

Kannst du - maki - mir da noch einen Tipp geben? Vielleicht ist das der letzte Punkt... Da hättest du mich glücklich gemacht und ich muss nicht mehr von meinen idiotischen Fehlschlägen berichten, die vermutlich noch nicht mal was mit DS zu tun haben.
Es gilt also: Ja, du hattest recht... DS funktioniert... :-D

 

[maki]

Persönlich hätte ich anstatt iPOJO oder "nacktem" DS lieber zu SpringDM oder gleich zu Guice/Peaberry gegriffen, letzteres ist richtig "sexy", aus SW Entwickler Sicht

Beschreibe doch mal dein Problem beim binden/nutzen des Services, vielleicht liegt es daran dass du einfach zu früh damit arbeiten willst (zB. im Activator, static o.ä.).

Eine DS "Komponente" nutzt DS Services recht einfach, views sollten ime einen manuellen Lookup in der OSGi Service Registry machen müssen (wenn man nacktes DS verwendet).

 

[dzim]

Also erst mal alles nacheinander: Ich werde mir die Kombo "Guice/Peaberry" mal anschauen... Letzten endes fange ich gerade erst mit Services an... Ich will aber einen alten Teil des Quellcodes los werden, der mir aus heutiger Sicht recht verfrickelt vorkommt - und wenn sich etwas besser als das hier gerade bedienen lasst und es sich in den Equinox-Container integrieren lässt... Fein!

Also ich mache nichts im Aktivator. Ich brauche dass "erst" in einem View. Ich hab da eine Plugin-Navigation und die soll nun endlich, mithilfe des Services, so gestalltet werden, dass ich nicht unterschiedliche Anwendungen für unterschiedliche Benutzergruppen (mit jeweils spezifischen Plugins) bauen muss, sondern nur eine Anwendung hab und aufgrund der Rechte des Nutzers eben nur die notwendigen Plugins aktiviert/dargestellt/verfügbar werden. Simple Sache eigentlich. Dachte ich jedenfalls

Hier noch mal kurz meine beiden Komponentenbeschreibungen - vielleicht ist da ja schon der Wurm drin:

ServiceImpl
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="pcpServices">
<implementation class="x.y.z.ds.services.Services"/>
<service>
<provide interface="x.y.z.servicedef.IAvailablePluginService"/>
</service>
</scr:component>
[/xml]

ServiceConsumer
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="pcpServices">
<implementation class="x.y.z.servicedef.consumer.GlobalServiceConsumer"/>
<reference bind="setAvailablePlugins" cardinality="1..1" interface="x.y.z.servicedef.IAvailablePluginService" name="IAvailablePluginService" policy="static" unbind="unsetAvailablePlugins"/>
</scr:component>
[/xml]

Ich müsste also wohl den von dir genannten OSGi Service Registry Lookup machen. Nur wie? Tut mir leid, aber ich steh gerade im Wald... :-/

 

[maki]

Das erste XML Snippet, also ServiceImpl (der Provider) stimmt ja dann imho, zumindst sehe ich auf die schnelle keinen Fehler.

Wenn der Consumer keine Component ist (also auch ein DS Service, vereinfacht ausgedrückt) wie bei einer View, kannst du dir auch die component.xml sparen, bringt ja nix

Der Weg wäre in diesem falle, die view einen "manuellen" Lookup in der OSGi Serviceregistry machen zu lassen, so als ob gar kein DS im Spiel wäre und es sich nur um normale OSGi Services handelt (DS spielt dann keine Rolle).
hab jetzt auf die schnelle kein Praxisbeispiel, ist aber wirklich Basis OSGi Wissen, lars Vogel hat hier ein Beispiel (unter "Use your service"), zwar im Activator, geht aber auch woanders, musst dir halt den BundleContext holen: OSGi with Eclipse Equinox - Tutorial

Musst darauf achten dass das "View" Plugin auf Lazyloading steht, sonst startet u.U. die View bevor der Service verfügbar ist.

 

[dzim]

Also kurz und Bündig: Ich erfrage dann eine Instanz meines Interfaces doch via

ServiceReference reference = context
			.getServiceReference(x.y.z.servicedef.IAvailablePluginService.class.getName());
service = (IQuoteService) context.getService(reference);

oder besser: Ich rufe irgendwo im View, wo ich es brauche, einfach folgendes aus (ich hab es "einfach" mal in den Konstruktor getan)

		Bundle bundle = Platform.getBundle(SSDToolPlugin.PLUGIN_ID);
		if (bundle != null) {
			ServiceReference reference = bundle.getBundleContext()
					.getServiceReference(
							IAvailablePluginService.class.getName());
			IAvailablePluginService service = (IAvailablePluginService) bundle
					.getBundleContext().getService(reference);
		}

Na ich bin mal gespannt, was da passiert...

[edit]
Erstens: ES GEHT! Ich glaub's nicht... Danke maki!!!

Zweitens: Wäre es denn sauberer, den Consumer auch noch mal zu verkapseln?
[/edit]

 

[maki]

Ja, so sollte das sein.
Natürlich erst den Service suchen nachdem er da ist, die activation policy nicht vergessen

 

[dzim]

Da sag ich glatt zwei mal Danke!

 

[maki]

Zweitens: Wäre es denn sauberer, den Consumer auch noch mal zu verkapseln?

Wüsste jetzt ehrlich gesagt nicht wie, ausser mit DI Frameworks wie zB. Guice/Peaberry oder SpringDM, da merkst du dann gar nix mehr von OSGi/DS etc. pp.

Nebenbei, iPOJO, SpringDM, Guice/Peaberry sind untereinander völlig kompatibel was das referenzieren von deklerativen Services betrifft, sie kappseln alle nämlich nur DS bzw. OSGi
.. und wie du siehst, ist auch ein deklerativer Services nur ein OSGi Service, der halt anders erzeugt wird (vom extender) und im normalfall auch anders verteilt (für DS Komponenten), aber genutzt werden kann er wie ein stinknormaler OSGi Service.

Eclipse 4 setzt übrigens auf ein eigenes DI Framework und DS ist da Standard, Eclipse 3 hat noch die PluginRegistry parallel zur OSGi Sefrvice Registry, die Pluginregistry ist Altlast, statisch und nciht "synchronisiert" mit der OSGi Serviceregistry.
Kurz: In E4 wird es einfacher (deklerative) OSGi Services aus Views zu nutzen, so als ob du jetzt schon ein DI Framework nutzen würdest.

 

[dzim]

Verstehe, danke für den Tipp.
Hab vorhin noch mal ein bisschen gegooglet und mit Guice angeschaut. Klingt auf jeden Fall nicht schlecht!
Wird in E4 eigentlich auch der Service per Annotation deklariert? Und ist das eigentlich auch über die Compatibility Layer nutzbar?