Deployable Plugin Testbarkeit und Enums als Implementation class

Hallo zusammen,

ich bin gerade zu OSGI gekommen, wie die Jungfrau zum Kinde. Für ein Tool, das wir einsetzen, habe ich ein Deployable Plugin geschrieben. Das funktioniert auch soweit.

Da die Implementierungsklasse selbst keinen Status hält und per Konfiguration sowieso ein Singleton ist, würde ich die Implementierung nun gerne anstatt mit einer Klasse mit einer Enum realisieren. In Tutorials werden aber immer nur Beispiele mit echten Klassen angegeben. Auch eine Google-Suche nach “OSGI Plugin implementation enum” u.ä. ergab nix. Bevor ich jetzt den kompletten Build-/Deploy-Zyklus durchziehe, nur um dann festzustellen, dass Enums als Implementierungen nicht unterstützt werden, wollte ich mal fragen, ob das in OSGI zulässig ist?

Und das bringt mich gleich zur nächsten Frage: Die Funktionalität meines Plugins kann ich wunderbar mit JUnit testen, aber ob der ganze Überbau stimmt, sehe ich erst nach dem Deployment. Gibt es eine Möglichkeit, das bereits in der IDE (Eclipse) irgendwie zu verifizieren?

Da die Implementierungsklasse selbst keinen Status hält und per Konfiguration sowieso ein Singleton ist, würde ich die Implementierung nun gerne anstatt mit einer Klasse mit einer Enum realisieren. In Tutorials werden aber immer nur Beispiele mit echten Klassen angegeben. Auch eine Google-Suche nach „OSGI Plugin implementation enum“ u.ä. ergab nix. Bevor ich jetzt den kompletten Build-/Deploy-Zyklus durchziehe, nur um dann festzustellen, dass Enums als Implementierungen nicht unterstützt werden, wollte ich mal fragen, ob das in OSGI zulässig ist?

Egal ob zulaessig oder nicht, wuerde pesoenlich davon Abstand nehmen, Enum als Singletons/Services ist nuetzlich in einem „normalen“ Java Environment, OSGi und JEE bringen da aber Unterstuetzung mit, da bringen Enums IME keine Vorteile.

Ansonsten: Ich hoffe du meint mit „Singleton“ nicht ein GoF Singleton mit static Zugriff auf die einzige Instanz, OSGi bietet da bessere Moeglichkeiten (Entweder mit SPring, Guice oder nacktem OSGi), die static Geschichte funzt nicht wirklich als OSGi Service.

Und das bringt mich gleich zur nächsten Frage: Die Funktionalität meines Plugins kann ich wunderbar mit JUnit testen, aber ob der ganze Überbau stimmt, sehe ich erst nach dem Deployment. Gibt es eine Möglichkeit, das bereits in der IDE (Eclipse) irgendwie zu verifizieren?

Was nicht genau was du mit „JUnit“ meinst :wink:
Unittests, oder Integrationstests?
Beides kann man mit JUnit schreiben, man sollte sowieso immer beie Testarten schreiben um die SW/Komponente zu testen.

Ansosnten empfehle ich fuer OSGi immer auhc Systemintegrationstests zu schreiben, also alle noetigen Bundles + OSGi platform hochfahren.

Egal ob zulaessig oder nicht, wuerde pesoenlich davon Abstand nehmen, Enum als Singletons/Services ist nuetzlich in einem “normalen” Java Environment, OSGi und JEE bringen da aber Unterstuetzung mit, da bringen Enums IME keine Vorteile.

Stimmt, großartig von Vorteil ist das nicht. Aber bei reinen Service-Implementierungen nur mit Methoden ohne eigenen Status nehme ich halt gerne Enums als Implementierung. Nicht nur im OSGI-Umfeld, bspw. auch Comparator-Implementierungen etc. Ich seh halt nicht ein, dass ich eine normale Klasse mit Konstruktor habe, der theoretisch mehrmals aufgerufen werden kann.

Ansonsten: Ich hoffe du meint mit “Singleton” nicht ein GoF Singleton mit static Zugriff auf die einzige Instanz, OSGi bietet da bessere Moeglichkeiten (Entweder mit SPring, Guice oder nacktem OSGi), die static Geschichte funzt nicht wirklich als OSGi Service.

Seit Java 5 verwende ich dieses Pattern praktisch überhaupt nicht mehr. Einfach EnumKlasse.INSTANCE und gut. Habe mich im Ursprungspost auch etwas blöd ausgedrückt. Die Klasse ist im Moment natürlich KEIN Singleton. Sie hat ja einen public no-Arg Konstruktor. Sie ist per Manifest-Eintrag als Singleton konfiguriert. Jedenfalls glaube ich das, weil ich da folgende Zeile drinnen habe:

Bundle-SymbolicName: <symbolischer Name>;singleton:=true

Was nicht genau was du mit “JUnit” meinst
Unittests, oder Integrationstests?

Ich meine damit, dass ich wunderbar alle Methoden einzeln durchtesten kann (also Unittest). Aber das ist ja nur die halbe Miete. Ob ich alles andere richtig gemacht habe (component.xml etc.), sehe ich leider immer erst nach dem Deployment.

[…]also alle noetigen Bundles + OSGi platform hochfahren

Ich glaub, das ist genau das, wonach ich suche. Werte mich da wohl tiefer einarbeiten müssen…

Habe inzwischen etwas rumgelesen und bin auf die Möglichkeit gestoßen, eine Factory zu definieren. Damit kann ich dann ja zurück geben, was ich will. Wäre das ein Ansatz?