OSGi und native Libraries

BDiegelmann

BDiegelmann

Grünschnabel
Servus,

beschäftige mich seid neustem mit OSGi, und muss ne Hardwareanbindung programmieren.

Hab mich schon mit der Device Spezifikation rumgeschlagen, aber weiß nicht so genau od das für meine Zwecke überhaupt nötig ist.

Ich hab vom Hersteller der Hardware eine Java-Anbindung sprich jni-Anbindung an die DLL´s bekommen. Und die würd ich gern verwenden.

Kann mir jemand sagen wie ich da am besten vorgehen soll?

Gruß
 
Den Thread hatte ich schon gelesen.

War aber nicht ganz das was ich gemeint hatte. Es gibt doch laut der OSGi Spezifikation ne definierte Device Anbindung.

Brauch ich das für diesen Fall, oder mach ich einfach ein Bundle das dann den Treiber implementiert?

Den ganzen System.loadLibrary("My"); brauch ich gar nicht, da der Hardwarehersteller schon ein JAR-File gemacht hat das ich benutzen kann. Quasi nen Wrapper für die DLL.
 
Hallo!

Also wenn dir dein Hersteller schon einen Java Wrapper mitliefert brauchst du einfach nur das Jar in den Bundle-Class Path zu legen und schon kanns losgehen. Weiterhin kommt es nun drauf an wie die native Bibliothek (dll unter windows/so unter unix/linux) von diesem Wrapper behandelt / geladen wird. Manchmal packen die Hersteller die native Libs mit ins Jar rein, die dann durch die Wrapper - API beispielsweise über einen static Initializer Block beim Laden einer (meist zentralen) Klasse irgendwohin ausgepackt und von dort mit System.loadLibrary von der JVM geladen wird. Manchmal mußt man aber die native Lib für das System über eine Umgebunsvariablle auffindbar machen (Path/LD_LIBARRY_PATH)... das sollte in der Doku zu dem Wrapper stehen.

Wie gesagt wenn du die Native Library im Bundle deklarierst übernimmt die OSGi Runtime das Laden der native Lib so dass du dich darum nicht mehr kümmern brauchst... kommt eben drauf an wie dein Hersteller den Wrapper konzipiert hat.

Brauch ich das für diesen Fall, oder mach ich einfach ein Bundle das dann den Treiber implementiert?
Zum Vergrößern anklicken....
In der Regel ist es eine gute Idee Third-Party-Libraries die von mehreren anderen Bundels gebraucht werden in ein eigenes "Third-Party-LibraryBundle" auszulagern.

Gruß Tom
 
Der Wrapper ist so programmiert, das die dlls im Suchpfad der VM liegen müssen. Also system32 oder so was.

Ein eigens Bundle wollte ich schon machen. Die Frage ist nur, ob ich diesen ganzen Overhead mit dem DevideManager, DeviceCategory und so weiter machen muss/soll.

Ist wenn ich das richtig verstanden habe ja eigentlich für Plug´n Play Geräte oder UPnP. Und das ist in dem Fall ja nicht so.
 
Hallo!

Der Wrapper ist so programmiert, das die dlls im Suchpfad der VM liegen müssen. Also system32 oder so was.
Zum Vergrößern anklicken....
Dann kannst du IMHO die native Lib (wenn du denn nun das entsprechende Library-Bundle erstellst) auch über Bundle-NativeCode laden lassen.

Ein eigens Bundle wollte ich schon machen. Die Frage ist nur, ob ich diesen ganzen Overhead mit dem DevideManager, DeviceCategory und so weiter machen muss/soll.

Ist wenn ich das richtig verstanden habe ja eigentlich für Plug´n Play Geräte oder UPnP. Und das ist in dem Fall ja nicht so.
Zum Vergrößern anklicken....
Also ich weis nicht ob du diese DeviceManager/DCategory Geschichten überhaupt brauchst... ich denke ein 08/15 Bundle mit einem einfachen Activator und einem entsprechenden bundle-Manifest tut den Job.

Für ein eigens Bundle spricht halt die Versionierung und die Updatemöglichkeit.

Gruß Tom
 
Gut, dann war meine Annahme richtig das nicht über den DeviceManager zu machen. Danke.

Der Hersteller hat mehrere DLL mitgeliefert, sprich wie bei jni üblich, die ursprünglichen DLL´s und dann hab ich da noch ne andere angepasste DLL und zusätzlich halt die JAR-Datei mit den Java Klassen.

Ich denke ich liege da richtig, wenn ich die alle per native Code laden lasse (Ausnahme JAR)?

Was passiert dann genau beim Laden?

Brauch ich die dann nicht mehr in einen Suchpfad zu kopieren?
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück