Hallo zusammen,
ich arbeite mich gerade in die Entwicklung von Anwendungen mit OSGi ein.
Dafür verwende ich Eclipse Equinox und in Eclipse klappt auch alles
wunderbar mit der OSGi-Console und die Plugins laufen auch.
Wenn ich jetzt aber "org.eclipse.osgi_XX" (XX = Versionsnummer) in der
Eingabeaufforderung von Windows aufrufe starten es scheinbar nicht
richtig. Jedenfalls erscheint nicht das "osgi>" am Zeilenanfang und ich
kann auch keine Eingaben tätigen. Hatte jemand ein ähnliches Problem
oder hat eine Idee was ich falsch mache? Einen Vorschlag für ein anderes
OSGi-Framework nehme ich auch gern an, dann sieht man gleich inwieweit
die Plugins portabel sind.
MfG von der Ostsee
Willkommen in der Welt von OSGi. Wo viel versprochen wird, wenig
gehalten wird und noch weniger funktioniert. Wo dir ein Traum von
Flexibilität verkauft wird, Flexibilität die du nicht brauchst, die es
nicht umsonst gibt und nur in Ausnahmefällen funktioniert. Und wo
Debuggen ein Job für einen ist der Vater und Mutter erschlagen hat.
Wenn du dich weiter ärgern willst: Apache Felix.
Hannes Jaeger schrieb:> Wenn du dich weiter ärgern willst: Apache Felix.
Habe hier eigentlich eher auf Hilfe und nicht Stoff für weitere
Frustration gehofft. Habe es trotzdem mal gegoogelt und auch
(irgend)etwas davon scheint es auch in Eclipse zu geben.
Ein Ansatz meinerseits: Kann es etwas mit der installierten JAVA-Version
zu tun haben? Habe JAVA 7 auf meinem Rechner.
Robert B. schrieb:> ... starten es scheinbar nicht richtig.
Möglicherweise fehlen dann bestimmte Umgebungsvariablen, die Eclipse
mitliefert, aber nicht gesetzt sind, wenn Du es "von Hand" aufrufst.
Oder die Art des Aufrufs selbst unterscheidet sich; Eclipse verwendet
möglicherweise Kommandozeilenargumente, die Du nicht verwendest.
Herausfinden kannst Du das mit dem ProcessExplorer, sieh Dir dazu die
Eigenschaften des von Eclipse erzeugten "osgi"-Prozesses an (hier werden
sowohl die Kommandozeilenparameter als auch die Umgebungsvariablen
angezeigt), und vergleiche das mit den Eigenschaften des "von Hand"
erzeugten "osgi"-Prozesses. Wenn das eine Java-Anwendung ist, kannst Du
auch sehen, welche Java-Runtime verwendet wird.
Toll dass da jemand auf OSGi herumhackt und dann Felix empfielt: eine
weitere OSGi-Implementierung ...
Zum Thema: Wie startest du dein Programm genau? Ich verwende bislang nur
RCP und dort kann ich mit "./meineAnwendung -console" die exportierte
Anwendung starten.
Tux schrieb:> Wie startest du dein Programm genau?
Ich gehe in den "eclipse/plugin"-Ordner und dort rufe ich die
Eingabeaufforderung auf. Da rufe ich dann die .jar Datei auf.
Mein vollständiger Aufruf:
Ein weiterer Punkt, den Du mit dem Process Explorer überprüfen solltest,
ist das Arbeitsverzeichnis, d.h. das Verzeichnis, aus dem heraus Java
gestartet wird. Bei Deinem Beispiel ist das "C:\Program
Files\eclipse\plugins".
Und außerdem solltest Du sehen, welcher Java-Interpreter verwendet wird.
Du rufst "java" auf; es gibt aber auch "javaw".
All das zeigt der Process Explorer.
Viel Erfolg.
Hannes Jaeger schrieb:> und noch weniger funktioniert
Komisch, bei mir funktioniert das alles wunderprächtig, aber ich lese
auch nicht nur die Werbebroschüre sondern das Datenblatt (Spec+Docu des
Frameworks).
Rufus Τ. Firefly schrieb:> Und außerdem solltest Du sehen, welcher Java-Interpreter verwendet wird.> Du rufst "java" auf; es gibt aber auch "javaw".
javaw ist aber im Prinzip nur die "Konsolenfensterfreie" Version
Robert B. schrieb:> Ein Ansatz meinerseits: Kann es etwas mit der installierten JAVA-Version> zu tun haben? Habe JAVA 7 auf meinem Rechner.
Nein das ist völlig egal...
Robert B. schrieb:> Habe es trotzdem mal gegoogelt und auch (irgend)etwas davon scheint es> auch in Eclipse zu geben
Erstmal solltest du unterschieden zwischen OSGi Runtime und
Implementierung. Sowohl Equinox als auch Felix bieten eine
Implementierung für das OSGi-Framework und Implementierungen diverser
(optionaler) Services. Die kann man dann auch mischen. Ich nutze z.B.
Equinox als OSGi-Framework, aber diverse Standardservices von Apache
Felix die mir dort "besser" gefallen.
Wenn du aus Eclipse heraus etwas startest werden gewisse Runtimeoptionen
mitgegeben um es zu erleichtern. Gewissermaßen eine Eclipse Installation
ohne GUI. Willst du außerhalb von Eclipse das ganze laufen lassen hast
du zwei Möglichkeiten:
- Du definierst ein Produkt und exportierst dieses mit der Option
"Include Native launcher Artifacts", dann erhälst du gewissermaßendas,
was Eclipse auf deren Seite als DL anbietet: Ein (nativer) Launcher,
welcher aus einer vordefinierten Verzeichnisstruktur dir das Framework
und die Konfig ausliest.
- Du nutzt nicht den Launcher, dann musst du das "start-jar" passend
selbst aufrufen, die Doku dafür findest du hier:
http://www.eclipse.org/equinox/documents/quickstart-framework.php dorst
steht einaml wie die Konfig aussehen muss, und wie man das auch
konfigurieren kann das er alles was in Plugins liegt automatisch lädt.
Sowas gibt es auch für Felix, da läuft es halt etwas anders:
http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html
Falls dir das alles zu "Basic" ist, kannst du auch auf eine "OSGi based
runtime" wie z.B. Karaf (https://karaf.apache.org/) zurückgreifen,
welche ein völlig vorkonfiguriertes OSGi Produkt liefert, incl.
Betriebsystemintegration für Hintergrunddiesnste wo du ggf. nurnoch
deine Bundles reindeployen musst.
*Zu deinem Problem*: Eclipse hat in der "neuen" Version die
Konsoleimplementierung gewechselt. Siehe hier:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371101
d.h. es ist ein (leider in obiger Doku nicht explizit genannter da auf
alte Version bezogener) zusätzlicher Aufrufparameter nötig:
Läubi .. schrieb:> Hannes Jaeger schrieb:>> und noch weniger funktioniert>> Komisch, bei mir funktioniert das alles wunderprächtig,
Tschuldigung, aber wenn du so einen Scheiß
>
für normal hältst ...
Das ist nämlich genau das typische OSGi Rumgewichse. Angeblich läuft
alles automatisch, aber damit es dann läuft darf man 12-stellige
Versionsnummern eintippen. Für Akademiker die sonst nichts zu tun haben
mag das völlig OK sein. Für Leute, die echte Software für echte Kunden
unter echtem Zeitdruck mit echten Robustheits- und
Performance-Anforderungen nicht nur einmal, sondern wiederholbar, zum
Laufen zu bekommen müssen ist dieses OSGI-Gewichse mit nur eine sinnlose
Qual.
Hannes Jaeger schrieb:> ...
Was soll den dieser emotionale Ausbruch jetzt?
Ich habe hier den absoluten Low-Level Aufruf genannt, und das der
DATEINAME für die Jar-File eine Versionsnummer enthält ist doch wohl
absolut üblich im Java Umfeld.
Und ich habe einen Link zu einem Produkt genannt, welches all diesen
Low-Level Kram abnimmt.
Falls du dennoch ein einer echten Diskussion mit Argumenten interessiert
bist, mach doch bitte eine eigenen Thread auf, das hilft dem TE in
keinster Weise weiter. Ebensoweinig ob Java, Basic, Adurino, C oder
Assembler die wahren Heilsbringer sind.
Hannes Jaeger schrieb:> ür Akademiker die sonst nichts zu tun haben mag das völlig OK sein. Für> Leute, die echte Software für echte Kunden unter echtem Zeitdruck mit> echten Robustheits- und Performance-Anforderungen nicht nur einmal
Schau dir einfach einmal an welche Firmen hinter OSGi stehen und das
einsetzen, da sind ganz sicher nicht nur Akademiker dabei. Also einfach
mal Scheuklappen ab, und die eigene Meinung (welche dir ja unbenommen
ist) nicht als die Ultimative Wahrheit sehen. Oder mal etwas bei dem
schönen Wetter an die frische Luft gehen, dann muss man nicht in solchem
unqualifiziertem Ton Dinge runtermachen welche man nicht versteht oder
nicht "mag".
