Eigenen Addon-Loader machen?

oOJavaNeulingOo

Bekanntes Mitglied
Guten Morgen!

Ich wollte nachfragen, wie man einen eigenen Addon-Loader machen kann. Also wenn ich zB meine Hauptjar in einem Ordner "Test" liegen habe, liegt dort noch ein Ordner "Addons", in welchem andere JAR-Dateien liegen - Meine Hauptjar soll dann diese laden. Natürlich auch mit einem System, dass es einfacher geht: In den Addon-Jars soll eine TXT Datei liegen, welche den Pfad zur Hauptklasse zeigt, und diese Hauptklasse soll eine Klasse zB "Addon" von meinem Hauptplugin extenden, und dann muss eine methode ausgeführt werden.

Quasi so:

Test:
-Hauptjar:
--Main Klasse, lädt andere jar dateien
--Addon Klasse, mit einer "activate" methode
-Addons:
--Jar #1:
---info.txt
----main: com.iwer.iwas.hauptklasse
---haupklasse
----extends Addon
-----Override activate

MfG
 

oOJavaNeulingOo

Bekanntes Mitglied
Vielen Dank für die Antworten!

@Noctarius Hättest du vielleicht einen Beispiel für den ServiceLoader :(?

Ich habe hier ( Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 7.3 Service-Factory ) nachgeschaut, jedoch erschließt sich mir nicht so ganz die funktionsweise dahinter..

@Marcinek Nö, zumindest nicht nach meinen Googleversuchen


Hier ein konkretes Beispiel:

Plugin.class:
Code:
public class Plugin{ public void enable(){}public void disable(){}}

Irgendeine Klasse, externe JAR (Die Jar in der die Klasse Plugin liegt wird natürlich eingebunden):
Code:
public class iwas extends Plugin{@Override public void enable(){System.out.println("Plugin wurde geladen!";}
 
Zuletzt bearbeitet:
T

tröööt

Gast
wenn es wirklich nur darum geht das die module zum start verfügbar sind und auch während der runtime nicht geändert werden sollen kann man schon ServiceLoader nutzen ...

so bald es allerdings komplizierter mit verwaltung und inter-kommunikation und möglichem entladen und so weiter wird brauchts schon einigen code ...

ich selbst hab da schon so meine eigenen mittel ... hab allerdings im zuge einer möglichen verbesserung das ganze mal hier erfragt und auch gute antworten bekommen : http://www.java-forum.org/allgemeine-java-themen/142247-konzeptfrage-modularen-systemen.html

habe nach dem letzten post noch n bissl dran rum gebastelt und hier und da noch was verändert und n bissl an die spezifische aufgabe angepasst ... aber seit dem auch nicht mehr wirklich dran gearbeitet ... habe zwar mal n proof-of-concept fertig gemacht ... aber da mir auf grund aktueller anderer projekt n bissl die zeit dafür fehlt und das eigentliche projekt wofür ich es brauche auch erstmal auf eis gelegt wurde halt nur soweit erstmal ...

sollte aber ein guter anfang sein ... und bei fragen kann ich dir da noch n bissl weiter helfen ... habe mich an den grundsätzlichen modularen aufbau gewöhnt und schreibe eigentlich alle codes nur noch so ...
 

oOJavaNeulingOo

Bekanntes Mitglied
Vielen Dank!

Ja, eigentlich soll das Modul nur beim Start geladen werden - Also, das einzige was ich brauche ist die Instanz der Klasse, welche ja eine andere Klasse extendet, und diese hat alle Methoden. Also dass ich die Klasse kriege -> activate methode aufrufe, und darin sind dann alle sachen wie zB commands registrieren und so
 

Noctarius

Top Contributor
Du machst ein Interface z.B. [c]com.example.foo.ServiceA[/c] und in dem externen Modul machst du dann eine entsprechende Implementierung des Interfaces. Um deinem Hauptprogramm dann die Implementierung bekannt zu machen, erzeugst du in "META-INF/services" eine Datei mit dem CanonicalName (also Classname + Package-Path "com.example.foo.ServiceA") als Dateinamen und schreibst den CanonicalName der Implementierung rein.

Um dann die entsprechenden Implementierungen zu holen (es könnte ja mehr als ein Modul eine Implementierung mitbringen):
Java:
ServiceLoader<ServiceA> serviceLoader = ServiceLoader.load(ServiceA.class)
for (ServiceA service : serviceLoader ) {
  // do something with the implementation
}

Die einzige Voraussetzung ist: Die Service-Implementierung benötigt einen Zero-Arg Constructor, damit der ServiceLoader sie instanziieren kann.
 

oOJavaNeulingOo

Bekanntes Mitglied
Vielen Dank!

Wenn ich jetzt allerdings ein Interface mache, kann ich das was ich machen wollte nicht machen - Oder ich hab das mit den Interfaces nicht richtig verstanden - denn ich will nicht nur eine activate Methode o.ä. drin haben, für welche ein simples INterface ausreicht, sondern eine Superklasse mit verschiedenen Methoden&variabeln - zB für konfigurationen und so. Und diese Methoden dürfen eben nicht leer sein :/

(Und das mit der Datei habe ich nicht ganz verstanden - Soll ich in den Plugins diese Datei erzeugen, oder in der Haupt-JAR? Wenn es in den Plugins ist, wäre es nicht sehr praktisch, da die Benutzer der Plugins ja nicht allzu viel Arbeit haben sollten :/
 
Zuletzt bearbeitet:
T

tröööt

Gast
HÄ ? ... also irgendwie widersprichst du dir in deinem vorhaben selbst ...

du willst ein modulares system ... aber dennoch alles im interface definieren ... das macht doch keinen sinn ...

das service-interface ist doch nur dafür da vorzugeben WELCHE methoden die service-implementierung zur verfügung stellen muss ... man könnte zwar das was du da sagst mit ner abstrakten super-klasse machen ... aber das ergibt trotzdem keinen sinn ... denn deine module sollen doch deine eigentliche haupt-anwendung erweitern ... warum willst du dann den code der eben nun mal in die module gehört in deiner haupt-anwendung verpacken ... dann brauchst du auch keine module mehr ...


und das beispiel hast du schon gegeben : du hast n interface und in einer implementierung schreibst du den code der ausgeführt werden soll ... warum willst du jetzt plötzlich doch was anderes ... oder hast du das prinzip von modularen systemen , ServiceLoader und interfaces nicht verstanden ?

das verlinkte thema setzt natürlich gewisses grundverständnis vorraus ... aber was ein interface ist , wie man es verwendet und was man mit machen kann ... findet man in der FAQ ... und bei fragen zum ServiceLoader gibts auch genug infos im Sun-tutorial ...

mehr als beispiele können wir dir nicht geben ... aber wenn du dir selbst widersprichst und es scheinbar nicht wirklich verstanden hast ... dann müsste man sich darüber erstmal unterhalten
 

oOJavaNeulingOo

Bekanntes Mitglied
Huch, ich hab's hingekriegt Oo

Aber ich hätte trotzdem eine zwei Fragen:

- Wie kann ich vor System.out.prinln Nachrichten etwas hinzufügen? zB die Uhrzeit. Ich habe zwar eine "Manager" Klasse, welche es dem Plugin erlaubt eine Methode aufzurufen welche eben ein systemout mit etwas davor erzeugt, jedoch will ich normale system out nachrichten nicht blockieren (Per Filter) - Somit muss ich irgendwie automatisch etwas vordran "kleben"...

- Wie kann ich eben statt nem Interface eine Klasse extenden? Wofür ich es brauche? Ganz einfach:

Zurzeit ist es so:

Plugin implements Interface
- vom interface implementierte klassen, inhalt muss aber selbst geschrieben werden
Externer Manager
- Diverse Methoden

Nun will ich es aber so machen:

Plugin extends Iwas
- Methoden, falls vorhanden - Also nicht benötigt
- Diverse Methoden, welche nicht über externen manager aufgerufen werden müssen
 
M

Marcinek

Gast
Hallo,

ich würde mal ein Grundlagenbuch heranziehen.

Sichwörter wären: Abstrakte Klassen, Polymorphie.

Anschließend implementierst du so ein PluginSystem.

Gruß,

Martin
 
T

tröööt

Gast
Huch, ich hab's hingekriegt Oo

Aber ich hätte trotzdem eine zwei Fragen:

- Wie kann ich vor System.out.prinln Nachrichten etwas hinzufügen? zB die Uhrzeit. Ich habe zwar eine "Manager" Klasse, welche es dem Plugin erlaubt eine Methode aufzurufen welche eben ein systemout mit etwas davor erzeugt, jedoch will ich normale system out nachrichten nicht blockieren (Per Filter) - Somit muss ich irgendwie automatisch etwas vordran "kleben"...

- Wie kann ich eben statt nem Interface eine Klasse extenden? Wofür ich es brauche? Ganz einfach:

Zurzeit ist es so:

Plugin implements Interface
- vom interface implementierte klassen, inhalt muss aber selbst geschrieben werden
Externer Manager
- Diverse Methoden

Nun will ich es aber so machen:

Plugin extends Iwas
- Methoden, falls vorhanden - Also nicht benötigt
- Diverse Methoden, welche nicht über externen manager aufgerufen werden müssen

ich wiederhol mich hier eigentlich nur ungerne da bereits alles gesagt wurd ... aber ich versuch es dir mal an nem bleistift klar zu machen ..

gehen wir mal von ner abstract superclass aus ... dann hättest du sowas
Java:
public abstract class AbstractPlugin implements Plugin
{
	public abstract void doIt();
	public void info() { System.out.println("AbstractPlugin"); }
}
und ein modul ala
Java:
public class PluginImpl extends AbstractPlugin
{
	public void doIt()
	{
		//TO-DO
	}
}
und du callst auf PluginImpl die methode info() ... dann returned diese "AbstractPlugin" ... statt sinnvoller weise "PluginImpl" ...

daraus folgt : hier wäre eine implementierung von info() in der abstrakten superclass völlig banane ...

klar gibt es ausnahmen ... z.b. das registrieren von handlern oder sowas ... das könnte man einmal in der superklasse implementieren ... und mit final sogar vor override schützen ... aber sonst gibt es eigentlich eher weniger dinge wo es sinn macht ...


oder andersrum : nenn uns doch bitte mal EIN konkretes beispiel WARUM du logic in die super-klasse packen willst ... wirklich viele sinnvolle gründe fallen mir persönlich nicht ein ...
 

oOJavaNeulingOo

Bekanntes Mitglied
Das habe ich schon verstanden. Aber hier das Beispiel: Ich will eine (mehre, aber ich nehme als Beispiel mal nur eine davon) Methode, die zum Beispiel eine Konfigurations-Datei erstellt und lädt, erstellen, ohne dass sie in dem Plugin selbst erstellt werden muss. So dass der Benutzer quasi in einer Methode einfach createCfg oder wie auch immer die Methode heißen soll aufrufen kann, ohne den Inhalt der Methode selbst zu schreiben. Habe es zwar durch einen externen Manager gelöst - Jedoch wäre es halt schön gewesen dass der Manager quasi zur Klasse dazugehört :/
 
T

tröööt

Gast
hmm .. das wäre sicherlich schon irgendwie machbar ... also das man halt in die superklasse den speicher-code schreibt und dann in den implementierungen diese methode mit den passenden parametern called ... aber das macht nur sinn wenn es halb wirklich nur n paar parameter sind die sich unterscheiden ...

man könnte sowas z.b. mit nem properties-objekt machen und zusätzlich z.b. n datei-namen übergeben ...

sowas fällt halt in die von mir unten genannten ausnahmen ...

nur muss man sich bewusst sein : der code ist dann für alle sub-klassen genau gleich und kann nur über die parameter gesteuert werden ...
und wenn nun ein modul abweichenden code hat müsste man überschreiben ... was allerdings notwendig macht entsprechende methode nicht final zu deklarieren ...

ich rall zwar immer noch nicht was du mit "externer manager" meinst ... aber k ...

grundsätzlich gibt es halt die haupt-anwendung , das modul-system ... und die module ... und grundsätzlich sollten die module und die haupt-anwendung so gut wie nichts von ein ander wissen sondern sich nur über das modul-system als schnittstelle "unterhalten" (wie im link mit listener und event angemerkt) ...

Plugin implements Interface
- vom interface implementierte klassen, inhalt muss aber selbst geschrieben werden
Externer Manager
- Diverse Methoden
also erstes ist mir klar ... aber das andere : HÄ ?=!

Plugin extends Iwas
- Methoden, falls vorhanden - Also nicht benötigt
- Diverse Methoden, welche nicht über externen manager aufgerufen werden müssen
ähm ... ja ... WAS genau willst du jetzt ?
das mit den methoden hast du ja jetzt erklärt ... aber ich rall das mit dem manager und dem nicht-callen immer noch nicht ...

entweder hast du da noch einiges nicht verstanden oder hast einfach probleme dich richtig auszudrücken ...


und auch dein beispiel ist nur sehr dürftig ... und code fehlt komplett ...

versuchs doch mal als kleines beispiel so wie ich zu posten ... am besten einfach so wie es gerade ist ... das man auch mal nachvollziehen kann wovon du überhaupt redest
 
A

Akeshihiro

Gast
Also für mich persönlich wäre so eine Konfigurationsdatei kein Grund, nicht im Geringsten. Ich halte das so, dass jedes Plugin nur das tut, wofür es gedacht ist. Sowas wie eine Config zu erstellen und zu lesen wäre für mich eher Aufgabe des Sandkastensystems um das Plugin herum, also ein Context oder was auch immer, den das Plugin bekommt und bei bedarf auch nutzen kann (wird es sowieso müssen, z. B. um sich zu registrieren). Ein Plugin hat in meinen Augen nur eine bestimmte Aufgabe und alles andere hat es nicht zu interessieren. Hinzu kommt auch noch: wo soll diese Config abgelegt werden? Im Anwendungspfad, in einem bestimmten Ordner, Netzwerk, FTP? Ganz ehrlich, who cares? Das soll die Anwendung regeln und nicht das Plugin.

Abgesehen davon finde ich, dass das eine ganz schön gefährliche Abhängigkeit ist. Sollte sich was an der Basisklasse verändern, wäre unter Umständen bei einer neuen Version der Anwendung kein einziges Plugin mehr kompatibel. Wenn sich die Schnittstelle ändert, dann in jedem Fall nicht. Aber sollte sich z. B. was an der Implementierung ändern und man kommt somit zu einem anderen Verhalten, dann könnten die Plugins plötzlich ein undefiniertes Verhalten vorweisen. Das ist dann ein ziemlich blöder Seiteneffekt. Sollte man da alleine dran rumwerkeln, ist das vielleicht halb so wild (obwowhl ich keine Lust hätte nen Dutzend Plugins nur deswegen zu fixen und wieder neu zu kompilieren), aber sollten andere Leute für die Anwendung Plugins bereitstellen und dann dadurch gezwungen sein das zu fixen, dann werden die einem was husten.
 
T

trööööt

Gast
du widersprichst dir irgendwie selbst ...

erst geht es darum das sich bei so ner config die anwendung drum zu kümmern hat ... und im nächsten satzt erwähnst du dann das bei ner änderung die plugins nicht mehr kompatibel wären ... was ja dann schon irgendwie sinngemäß andeutet das sich wohl doch das plugin wieder selbst drum zu kümmern hat ...

entscheid dich doch mal für eins von beiden xD


btw : man muss zwischen context und scope unterscheiden ...
ist zwar richtig das die main-anwendung sich um die config des context kümmern sollte ... aber wenn ein plugin selbst noch eine zusätzliche eigene config hat sollte es sich darum selbst kümmern ... und der main-app lediglich sowas wie speicherort oder so überlassen ... wobei man dann natürlich auch sowas wieder bereitstellen müsste ...
ist halt alles sehr komplex ...
 

oOJavaNeulingOo

Bekanntes Mitglied
Urgs, sorry.. Hab mich gestern wirklich komisch ausgedrückt.. Neuer Versuch.
Zurzeit sieht die Hauptklasse eines Plugins so aus:
Java:
public class Pl implements Plugin {

	PluginManager manager;
	
	@Override public PluginManager getManager() {return manager;}
	@Override public void setManager(PluginManager arg0) {manager = arg0;}
	
	@Override public String getName() {return "bsp";}
	@Override public String getVersion() {return "v1.0";}


	@Override
	public void onEnable() {	}
	
	@Override
	public void onDisable() {}
	
	
}

Und der "PluginManager" ist das hier - Ist in der Hauptjar enthalten.
Java:
public class BasicManager implements PluginManager {

	private Accessor access = new Accessor();
	
	@Override
	public void out(Object o) {
		GlobalUtil.out(Level.INFO, o);
	}

	@Override
	public int pluginAmount() {
		return PluginLoader.amount();
	}

	
	@Override
	public Accessor getAccess(){
		return access;
	}

	@Override
	public File getDataFolder(Plugin pl) {
		return new File("./plugins/" + pl.getName());
	}
	
	@Override
	public void saveConfig(Plugin pl) throws Exception{
		File f = new File("./Plugins/" + pl.getName());
		if(! f.exists()){
			f.mkdir();
			new File(f, "Config.properties").createNewFile();
		}
	}
}

Was ich nun will, ist statt an diese Methoden mit getManager() zu kommen, sie einfach in die Hauptklasse einfügen! Aber wenn ich einfach mein Plugin Interface ca so erweitere:

public File getDataFolder(Plugin pl);

dann muss es ja, um zu funktionieren, in der Hauptklasse selbst drin sein - Und eben das will ich umgehen :D

Hoffe es ist verständlicher :(
 
A

Akeshihiro

Gast
@trööööt

Du hast das falsch verstanden. Ich meinte, dass wenn man eine abstrakte Klasse als Basisklasse für Plugins nimmt und sich daran irgendwas ändert, dann sind die Plugins mit der neuen Version der Anwendung nutzlos, weil dann keiner mehr garantieren kann, wie sich das Plugin dann noch verhält bzw. ob die Schnittstellen überhaupt noch passen. Daher bekommt der Pluginprogrammierer eben nur die Interfaces, die er für seine Plugins braucht und das wars.

Die Verwaltung der Configs kann die Anwendung locker übernehmen. Die Plugins bekommen dann eben beim Laden nur die Properties oder was auch immer und beim Speichern wird das auch nur mit Properties gehandhabt. Wie das Speichern dann aussieht, soll doch die Anwendung selbst machen (Datei, DB, ...). Aber gut, so hat jeder seine eigene Vorstellung von solchen Architekturen ...

@oOJavaNeulingOo

Das ist einfach. Mach deine Klasse Pl abstrakt, dann brauchst du die Methode da nicht nochmal leer implementieren.
 
Zuletzt bearbeitet von einem Moderator:

oOJavaNeulingOo

Bekanntes Mitglied
@Akeshihiro Nunja, entweder habe ich es nicht richtig verstanden - In diesem Falle sind meine nächsten Sätze sinnlos - Oder:
Wenn ich sie Abstrakt mache, haben sie aber immernoch keinen Inhalt. Und der Inhalt soll ja vorhanden sein, auch OHNE dass ein Benutzer irgendetwas dafür tun muss.
 
T

tröööt

Gast
@Akeshi
ach so meintest du das ... joar dann hab ichs echt falsch verstanden ... kann ja ma vor kommen ...

@TO
wenn du statt "Hauptklasse" mal das wort "Plugin-Implementierung" verwenden würdest wäre mir vielleicht schneller klar geworden was du meinst ...

grundsätzlich musst du dich fragen : wer greift von wo auf welche information zu und wer ist dafür verantwortlich was drin steht ...

auch wenn ich einiges anders gemacht hätte (wozu bitte braucht ein plugin einen getter der seinen manager returned ? nur der manager kennt das plugin direkt ... und das plugin kennt auch nur den manager direkt ... da brauchts kein "getManager" ... raus damit) ... will mir immer noch nicht ganz klar werden was du jetzt willst ... da du es ja auch nicht mal ansatzweise als code gepostet hast damit man sich auch nur irgendwas vorstellen könnte ..

fakt ist : im manager gibt es eine methode die auch von NICHT-plugins gecallt und wichtig sein kann ... außerdem legt der manager fest WO das plugin zu liegen hat ... womit getDataFolder und saveConfig so wie du sie implementiert hast auf jeden fall in den manager gehören ...

auch hätte ich den manager selbst nicht als modul ausgelegt ... zumindest nicht wenn ich nicht explizit vorgehabt hätte den manager selbst austauschbar zu machen ...

und auch das der manager beim loader nachfragen muss wie viele module geladen wurden ... das gehört direkt in den manager ... und der loader hat ihm dies zu melden (siehe mein code beispiel im verlinkten thread) ...

so wirklich plan und struktur erkenne ich in deinem vorhaben leider noch nicht ... und kann trotz größter bemühungen nicht verstehen was du hier eigentlich genau fragen willst ...

Akeshi kennt ja die ganzen threads drüben im tut.de forum ... vielleicht kann er die mal linken ... dann kannst du dir mal ansehen was da schon alles seiten weise an text drüber diskutiert wurde ... und das was bis jetzt am "saubersten" bei raus gekommen ist ist halt das hier : http://www.java-forum.org/allgemeine-java-themen/142247-konzeptfrage-modularen-systemen.html

klar gibt es genug fertiges zeug wo man sich nur noch n bissl an die gegeben API halten muss und fertig is ... aber wenn man sows selbst basteln will brauchts halt einiges an erfahrung und fähigkeit ... und so leid es mir tut ... da erkenne ich bei dir einfach nicht genug als das ich mit meiner erfahrung auf diesem gebiet sagen würde : joar du bekommst das mit n bissl hilfe schon hin ...

ich mein : alleine das es dir schon schwer fällt dich halbwegs verständlich auszudrücken und auch mal n bissl pseudo-code zu posten wie du dir das ganze am ende vorstellst .. auch wenns erstmal blöd aussieht ... zeigt das du doch noch n bissl was lernen musst ...
 

Noctarius

Top Contributor
Wenn ich die API richtig interpretiere muss dazu die externe JAR aber schon im Klassenpfad drin sein, der TO scheint aber sozusagen den Klassenpfad separat in einer Textdatei zu wünschen.

Bernd

Jein mit der Methode [c]load(Class<?>)[/c] stimmt das, du kannst aber auch explizit einen ClassLoader angeben [c]load(Class<?>, ClassLoader)[/c] (ServiceLoader (Java Platform SE 6)) und dieser könnte ein URLClassLoader sein den du selber aufgebaut hast.
 

Bernd Hohmann

Top Contributor
Jein mit der Methode [c]load(Class<?>)[/c] stimmt das, du kannst aber auch explizit einen ClassLoader angeben [c]load(Class<?>, ClassLoader)[/c] (ServiceLoader (Java Platform SE 6)) und dieser könnte ein URLClassLoader sein den du selber aufgebaut hast.

Ah ok. Wo liegt der Vorteil des ServiceLoader? Ich hab mal in den Source reingeschaut, so recht hab ich die Konstruktion nicht verstanden (ausser dass man in MANIFEST/service den Ort der Classfiles definieren kann).

Bernd
 

Noctarius

Top Contributor
Es ist eine Art Mini-DI direkt in Java. Wenn dir diese Art reicht, dann braucht man weder Guice, noch Dagger, noch Spring oder welches DI Framework auch immer. Genutzt wird es in Java z.B. um den XML Parser im Classpath zu finden (z.B. ein Xerces) und zur Not den mitgelieferten im JRE zu nutzen.
An was für Vorteile denkst du denn?
 
T

tröööt

Gast
wie gesagt : ServiceLoader hat schon seine da-seins-berechtigung ...
z.b. nutzen viele JDBC-driver den ServiceLoader um sich selbstständig beim DriverManager zu registrieren ... somit entfällt das lästige "Class.forName()" ... vorraussetzung : Driver liegt im CP

und für solche einfachen aufgaben kann man auch gut den ServiceLoader nutzen ... allerdings hat er als "standard-schnittstelle" ein paar einschränkungen wenn es um modulare entwicklung geht ... er ist halt nur zum laden da ... und auch wenn man mit Java7 und URLClassLoader arbeitet und so module wieder freigeben könnte ... muss man sich dennoch selbst um das restlose freigeben aller referenzen und resourcen kümmern ...
in anbetracht das man dies so oder so tun muss ... und die ServiceLoader-API wirklich nur als reinen "loader" nutzt ... ist die frage berechtigt : lohn es sich dann überhaupt ?

um das beispiel an diesem code http://www.java-forum.org/allgemein...eptfrage-modularen-systemen-2.html#post948820 zu verdeutlichen ... wäre der ServiceLoader lediglich nützlich um in der klasse ModuleLoader in der methode "void loadModule(File)" die zeilen 29 bis 33 zu ersetzen ... und das war es dann auch schon wieder ....
den ganzen krempel drum rum braucht man trotzdem damit das system funktioniert ...

und da frage ich mich persönlich : ist der serviceloader dann wirklich so viel besser wenn ich 5 zeilen durch 1 ersetzen kann ? ... ich meine ... was nimmt uns der serviceloader denn wirklich ab ? er findet anhand von META-INF/services die klasse die geladen werden soll und beschafft davon eine instanz vom classloader ... in meinem code passiert nichts anderes ... nur das ich halt das main-class attribut des manifest dafür missbrauche ...

und darum bin ich halt der meinung : da wo es sinn macht gerne ... aber es immer als "keule" dabei zu haben wenns mal um modulare entwicklung geht ist auch kein all-heil-mittel ... genau so wenig wie einiges andere was ich jetzt hier nicht ansprechen möchte ...
 

Noctarius

Top Contributor
Nö natürlich kein Allheilmittel aber einfacher als es selbst zu implementieren, besonders wenn man selbst noch "Anfänger" ist :) Wenn ich die Module nicht neuladen will, sondern nur ein System brauche das beim Starten automatisch alle im Classpath liegenden Module läd find ich den ServiceLoader super, wenn es darüber hinausgeht sollte man sich schwer überlegen auf OSGi zu wechseln, Abhängigkeiten unterhalb von Module-Classloadern aufzulösen macht keinen Spaß :D
 
T

tröööt

Gast
sollte man sich schwer überlegen auf OSGi zu wechseln

ja ... strike ... wie ich es einfach wusste das genau dieser spruch wieder kommen wird ...

aber naja ... ich habe mich mitlerweile lang und breit genug versucht klar zu machen das diese 4 buchstaben in den raum werfen das wohl schlechteste sind was man wohl in einer solchen situation machen kann ...

als hauptargument beziehe ich mich hierbei darauf das "OSGI" selbst lediglich eine vereinigung ist die eine allgemeine spezifikation erarbeitet ... zu dieser selbst aber KEINE implementierung entwickelt hat ...
folglich würde nun die diskusion beginnen : ja welches OSGI-framework denn nun ...

aber da ich ja bereits mehrfach vergeblich versucht habe genau diesen kampf gegen windmühlen zu kämpfen ... und mir selbst ja schon etwas gebastelt habe ... ist es mir mitlerweile völlig egal geworden ...

es wäre nur nett wenn all die jenigen die immer der meinung sind dies so einfach in raum zu werfen es wenigstens auch mal halbwegs erklären und versuchen würden ein paar der implementierungen zu nennen und gegeneinander zu vergleichen und ein für den user passendes system vorzuschlagen ...

wenn allerdings einfach nur OSGI in den ruam geworfen wird ... naja ... dann kann ich mir auch die specs holen und es am ende doch wieder selbst implementieren ... und dann einfach sagen : das ist meine OSGI-impl ... und ich wette das mindestens einer wieder ankommen würde in irgendeinem thread in dem man fragen über seine spezifische implementierung stellt kommt und sagt : "nimm doch OSGI" ... darauf würd ich n 100er wetten ... mit 10zu1 quote ... die 1000euro wären mir aber sowas von totsicher ...

ich versuchs also noch mal : wenn jemand der meinung ist so oberschlau und witzig zu sein um "OSGI" ins topic zu werfen ... dann soll er es auch bitte mal erklären und wenigstens EINE beispiel-implementierung nennen sowie deren vor- und nachteile ... ansonsten solltet ihr es einfach langsam mal lassen ...
 

Noctarius

Top Contributor
Tja vermutlich, weil es einfach genau für diesen Zweck entwickelt (spezifiziert) wurde. Generell hat sich OSGi in diesem Bereich auch neben JEE platziert ob man es wahrhaben will oder nicht.
OSGi hat eine ziemlich steile Lernkurve, das mag sein - was aber besonders an dem Export-Sichtbarkeitslevel liegt) aber wenn man erstmal drin ist, funktioniert es ohne Probleme. Am Anfang war es schwer OSGi fähige JARs zu finden (außer in der Eclipse-Welt, daher bin ich hier auch oft mit Leuten aneinander geraten, welche der Meinung waren "alles klein Problem", klar in der Eclipse-Welt ;-)) aber mittlerweile ist die Situation anders und die meisten OSS Projekte stellen OSGi fähige Bundles (java.net Projekte sind oftmals Ausnahmen).

Da aber fast alle JEE Application Server auf OSGi (z.B. Glassfish) wird auch hier die Situation immer besser.

Zu deiner Frage:
Du könntest Equinox nehmen (Eclipse), dies ist die Referenzimplementierung mit allen Features. Du kannst aber auch Apache Felix nehmen, der hängt immer kurz der Spec hinterher kann aber auch alles. Ansonsten gibt es noch Knopflerfish, damit habe ich selbst noch nicht gearbeitet, kann also nichts dazu sagen. Weiterhin gibt es noch einen ganzen Batzen an kommerziellen Implementierungen (ProSyst, eine von Samsung, ähm ka was noch) und auch so neben den drei schon genannten OSS Implementierungen weitere wie Concierge, Native-OSGi (implementiert in C++, noch nie mit gearbeitet) und Jadabs für Kleingeräte (glaube diese Impl ist nicht vollständig)

Welche Vor-/Nachteile die Implementierungen bringen ist eigentlich ziemlich sinnfrei, da sie eine Implementierung der OSGi Spec darstellen, ergo sind proprietäre Erweiterungen vielleicht ganz nett, stehen aber der eigentlichen Idee einer Spec (der Portierbarkeit) irgendwie im Weg.

OSGi bietet mir genau das was ich brauche wenn ich ein dynamisches System (Module hinzufügen, Module entfernen, Module aktualisieren, Module neustarten, Abhängigkeiten unterhalb von Modulen, einzelne Modul-Sandboxen, ....) benötige. Natürlich kannst du dir die Spec nehmen und eine entsprechende Implementierung selber entwickeln aber ich bin sicher, dass du schnell aufgeben wirst und entweder dein halbes OSGi nutzt oder eine der bestehenden Implementierungen nimmst. Die OSGi Spec ist an einigen Stellen / Features schon tricky und das ist keine "och das mach ich mal an einem Wochenende"-Aktion. Im Gegensatz dazu kann man den ServiceLoader und sein Prinzip in einer Stunde selbst nachbasteln.

Gerade die neueren OSGi Specs wie Blueprint bringen ein komplettes, Modul-übergreifendes Dependency Injection System mit welchen durch Spring (und Spring DM) inspiriert und großteils auch von SpringSource spezifiziert wurde.

Weiterhin bekommst du in jeder OSGi Runtime (Equinox, Felix, Knopflerfish oder dem ganzen Haufen der kommerziellen Runtimes - auch für Android) automatisch Configuration Management, Event System, einen Preferences Service, das komplette Bundle (Module) Management, User Service, erweiterte Sichtbarkeitsebenen, usw geschenkt. OSGi geht also weit über ein einfaches Modulsystem hinaus.

Ich habe mich auch lange gegen OSGi gewährt aber dieses komplette System selbst zu implementieren ist schwachsinn und sollte niemandem ernsthaft ans Herz gelegt werden.
 
Zuletzt bearbeitet:
T

trööt

Gast
der grund warum ich mich nicht weiter mit osgi befasse ist nicht etwa der das es mir zu komplex wäre oder der gleichen ... und mir ist durch aus bewusst das viele denen OSGI was sagt erstmal an equinox und eclipse denken ...

und osgi ist ja auch eine sehr durch dachte spezifikation und die implementierung ist sicher eine mammut aufgabe ... aber irgendwie fällt es mir immer schwer zu glauben das diejenigen die es den (meist anfängern (auf diesem gebiet)) fragenden an den kopf werfen davon überzeugt sind das es ausreicht ...

ich mein : es ist doch bereits klar geworden das TO hier nicht all zu viel plan von all dem nötigen basiswissen hat ... und da glaubst du ernsthaft er ist in der lage sich mit einem großen komplexen framework zu befassen ? ... sorry .. aber genau DAS ist für mich immer die schwelle wo ich mir denke : yup, und ich bin der diktator von süd korea ...

ganz erlich ... ich hab ja oben schon erwähnt WIE man man osgi umgehen sollte ... anstatt es einfach nur zu nennen ... und vermutlich brauch auch ich einfach nur mal nachhilfe auf diesem gebiet ... aber was haben wir hier nicht schon alles erlebt ... von "vampiren" bis hin zu "supergenies" ... und die erfahrung hat uns ja meist recht gegeben wenn viele der meinung waren : das wird nix ...

warum sollte es also mit OSGI so viel anders sein ... wo doch viele schon daran scheitern eine externe lib in den CP mit aufzunehmen ... ganz von der korrekten arbeitesweise "gegen ein interface" zu schweigen ...

ich habe versucht mit meinem persönlichen wissensstand in diesem gebiet halbwegs "simpel" zu helfen ... das natürlich wieder irgendwer beim stichwort "modular" die "OSGI-keule" rausholt war mir ja klar ...

vielleicht sollte ich in zukunft auf solche themen auch nur noch mit "OSGI" antworten ...
 

Noctarius

Top Contributor
Und ich habe es dem TO auch nicht vorgeschlagen, sondern auf deinen Post davor geantwortet. Wenn du noch mal fein nachliest fällt dir sicher auf, dass ich dem TO den ServiceLoader ans Herz gelegt habe, gerade weil er nicht das benötigte Basiswissen hat, weder so ein System selbst zu implementieren, noch OSGi oder ein anderes Framework dieser Art zu nutzen.

Manchmal habe ich bei dir das Gefühl du wartest nur auf die Chance irgendwo zu meckern / trollen ;-)
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
I Liste von Infos von einer eigenen Annotation in Liste speichern Java Basics - Anfänger-Themen 0
L Math.exp also eigenen Algorithmus Java Basics - Anfänger-Themen 2
B Email Client in der eigenen Software einbauen Java Basics - Anfänger-Themen 3
M Ist es möglich den Login in eine Drittseite für den eigenen zu benutzen? Java Basics - Anfänger-Themen 1
C Tabs in JTabbedPane wechseln, wenn Tabs in eigenen Klassen sind Java Basics - Anfänger-Themen 2
K Hashtable mit eigenen Konstruktor Java Basics - Anfänger-Themen 2
K JUnit: Objekte von eigenen Klassen vergleichen...geht nicht Java Basics - Anfänger-Themen 5
A mehrere Panels in eigenen Klasssen in einem Frame Java Basics - Anfänger-Themen 16
S Methoden eine Instanz einer eigenen Klasse als parameter übergeben Java Basics - Anfänger-Themen 9
Thallius Best Practice Events zwischen eigenen Klassen Java Basics - Anfänger-Themen 2
S Eigenen Listener zu eigenen Button! Java Basics - Anfänger-Themen 5
kaoZ Methoden Eigenen Sortier Methode erstellen Java Basics - Anfänger-Themen 5
H Eigenen Listener einbauen Java Basics - Anfänger-Themen 5
Pentalon Eclipse JUNO keine Vorschläge von Methoden bzw. Interfaces der eigenen Klassen Java Basics - Anfänger-Themen 5
Y Collection der eigenen Klasse Java Basics - Anfänger-Themen 10
M Größer der eigenen .jar ermitteln Java Basics - Anfänger-Themen 4
S JTabbedPane jeder Tab in einer eigenen java Datei? Java Basics - Anfänger-Themen 3
P Klassen Instanz einer Klasse in ihrer eigenen Definition erzeugen? möglich? Java Basics - Anfänger-Themen 4
L eigenen Baum schreiben Java Basics - Anfänger-Themen 5
E incompatible types bei eigenen Klassen Java Basics - Anfänger-Themen 7
W Datentypen Operatoren für eigenen Datentyp nutzen Java Basics - Anfänger-Themen 2
A Array einer eigenen Klasse sortieren Java Basics - Anfänger-Themen 11
N Eigenen Codesinn vergessen Java Basics - Anfänger-Themen 6
xehpuk In JUnit über eigenen Thread testen Java Basics - Anfänger-Themen 3
D Pfad zu "Eigenen Dateien" ermitteln Java Basics - Anfänger-Themen 8
M Verständnis-Probleme mit eigenen Klassen Java Basics - Anfänger-Themen 2
A Null Pointer Exception beim Erstellen eines Arrays aus einer eigenen Klasse Java Basics - Anfänger-Themen 3
F Klasse bzw Objekt in eigenen Thread auslagern Java Basics - Anfänger-Themen 3
M Datentypen Eigenen Datentyp toArray() Java Basics - Anfänger-Themen 4
C0FFEE Anwendung soll eigenen Dateinamen referenzieren Java Basics - Anfänger-Themen 13
Benji0815 Eigenen Listener schreiben Java Basics - Anfänger-Themen 13
Spin Eigenen Abstrakten Datentypen Java Basics - Anfänger-Themen 28
R eigenen Event schreiben Java Basics - Anfänger-Themen 16
S Vector von eigenen Klassen Java Basics - Anfänger-Themen 2
A Mehrere Instanzen einer eigenen Klasse in einem Array Java Basics - Anfänger-Themen 5
D JWS - Resourcen aus eigenen Jar laden? Java Basics - Anfänger-Themen 3
S Java Applet - Verbindung zum Eigenen Server Java Basics - Anfänger-Themen 2
E ArrayList mit eigenen typ serialisieren? Java Basics - Anfänger-Themen 1
Povlsen84 HashSet mit eigenen Datentypen Java Basics - Anfänger-Themen 6
G Protected Variablen außerhalb der eigenen Klassenhierarchie sichtbar Java Basics - Anfänger-Themen 5
S Addition von eigenen Objekten mit "+" Symbol Java Basics - Anfänger-Themen 19
M Einfügen eines eigenen Component Java Basics - Anfänger-Themen 21
A Im Chat eigenen Beitrag in Farbe zeigen Java Basics - Anfänger-Themen 8
G Eigenen Code mit einer Lizenz schützen Java Basics - Anfänger-Themen 2
G Vector eigenen Typs mit Daten füllen Java Basics - Anfänger-Themen 20
J Verwendung von eigenen Klassen in JSP Java Basics - Anfänger-Themen 2
B Ergenzungen und oder Updates von eigenen Anwendungen Java Basics - Anfänger-Themen 4
R Einfügen einer eigenen methode in ein Panel Java Basics - Anfänger-Themen 5
spacegaier Problem beim Laden eines Vektors mit eigenen Objekten Java Basics - Anfänger-Themen 4
F ArrayList eines eigenen Datentyps Java Basics - Anfänger-Themen 3
F Array einer eigenen Klasse erstellen. Java Basics - Anfänger-Themen 8
° Zugriff auf ein Objekt der eigenen Klasse Java Basics - Anfänger-Themen 2
F Array einer eigenen Klasse Java Basics - Anfänger-Themen 5
G JTable mit eigenen Model neu zeichnen Java Basics - Anfänger-Themen 4
E Eigenen datentypen erstellen Java Basics - Anfänger-Themen 14
C Eigenen Datentyp schreiben Java Basics - Anfänger-Themen 13
C Wie muss man hier aufrufen von 2 eigenen Klassen? Java Basics - Anfänger-Themen 6
D Mehrere JFrames in eigenen Klassen und Dateien? Java Basics - Anfänger-Themen 4
G eigenen Quelltext ausgeben Java Basics - Anfänger-Themen 8
J Attribut vom Objekt einer eigenen Klasse setzen Java Basics - Anfänger-Themen 6
A problem: importieren von eigenen klassen Java Basics - Anfänger-Themen 3
K Array von einem eigenen Objekt erstellen Java Basics - Anfänger-Themen 5
Dilandau array aus eigenen objekten erstellen? Java Basics - Anfänger-Themen 7
M Email versenden, ohne eigenen pop3-server? Java Basics - Anfänger-Themen 7
M Namen der eigenen Klasse ermitteln Java Basics - Anfänger-Themen 2
H probleme mit import von eigenen packages Java Basics - Anfänger-Themen 4
D betr. QuickJava (addon FF) Java Basics - Anfänger-Themen 5
Butzibu Image Loader lädt nicht alle Bilder: Java Basics - Anfänger-Themen 4
O Image Loader laedt bild nicht Java Basics - Anfänger-Themen 11

Ähnliche Java Themen

Neue Themen


Oben