Pluginschnittstelle

[Sekundentakt]

Hallo Gemeinde,

mein momentanes Projekt wird immer umfangreicher und es gibt regelmäßig Stellen, bei denen ich in die Klasse gehen muss, und Dinge im Code verändern muss, um etwas Neues zum Laufen zu bringen.

Meine Idee war es jetzt, eine Config-Datei (z.B. im XML-Format) zu erzeugen, die Klassenname sowie Init-Argumente enthält.

Beispiel:
<component class="org.java-forum.views.threads.ThreadList" maxDisplay="25" displayedDateFormat="yyyy"/>

Mein Plugin-System soll jetzt folgendermaßen vorgehen:
- Config-Datei einlesen
- Component-entries parsen
- Parameter in eine Map schreiben
- alle Klassen, die via Plugin initialisiert werden sollen, müssen im Konstruktor eine Map aufnehmen.

Idealerweise handelt es sich dabei um Factories, die aus den Parametern in den Maps Instanzen erzeugen.

Ich würde mir diese Pluginschnittstelle über Class.forName() und die Constructor-Implementierungen erarbeiten.
Da das aber ziemlich Low-Level ist, dachte ich mir, dass es wohl auch brauchbare Implementierungen dazu geben müsste.

Bei meinen bisherigen Recherchen bin ich nur auf LGPL oder GPL-Libraries gestoßen.
Kennt jemand ggf. Projekte, die unter BSD oder ASL 2.0 veröffentlicht worden sind?

Beste Grüße

 

[kay73]

Meine Idee war es jetzt, eine Config-Datei (z.B. im XML-Format) zu erzeugen, die Klassenname sowie Init-Argumente enthält.

Du bist auf dem besten Wege, den IoC container des Spring Frameworks nachzubauen.

 

[Sekundentakt]

Du bist auf dem besten Wege, den IoC container des Spring Frameworks nachzubauen.

Hi Kay,

danke für den Link!

Ganz kurz zu meinem Hintergrund:
Ich steige gerade erst in Java EE ein.

Meine Applikation ist so aufgebaut, dass nur ein Object, der "ApplicationContainer" oder das "ApplicationObject" (enthält die gesamte Businesslogik und auch primitive Formen für Views) erzeugt wird.
Das hat den Vorteil, dass ich es in Server-Klassen, Servlets oder sonst wo implementieren kann.

Die Anwendung an sich ist dennoch recht komplex.

Mit dem Konzept von Beans habe ich mich noch nicht auseinandergesetzt.
Mich würde jetzt aber interessieren, ob "ApplicationContext" und insbesondere Spring für mich dennoch die richtigen Werkzeuge sind?

Danke!

 

[maki]

Du bist auf dem besten Wege, den IoC container des Spring Frameworks nachzubauen.

Full ACK!

Wenn er dann damit fertig ist, kann er ja OSGi nachbauen

 

[Sekundentakt]

Full ACK!

Wenn er dann damit fertig ist, kann er ja OSGi nachbauen

Every Journey Has A First Step. Every Saga Has A Beginning.

Nein, im ernst: Bin ich da richtig?

 

[maki]

Nun, Spring IoC (treffender wäre Dependency Injection) ist ein DI Container, OSGi ist ein Plugin System.

Ob nachbauen richtig ist?
Naja, nur im kleinen Rahmen höchstens, wegen Grundlagenforschung, in proff. Bereich hat das imho nix verloren, auch wenn es noch einige Teams geben soll die am "Not invented here" Syndrom leiden.

 

[Sekundentakt]

Nun, Spring IoC (treffender wäre Dependency Injection) ist ein DI Container, OSGi ist ein Plugin System.

Es wäre beides neu für mich. Offenbar bin ich was die Begrifflichkeiten angeht noch nicht so ganz sicher.

Ich beschreibe am besten mal den Usecase:

Bei der Applikation sind bestimmte Reihen- und Rangfolgen hartcodiert und vorgegeben.

So wird z.B. erst der Request verifiziert, dann über ein paar Filter an bestimmte Objekte weitergegeben, um anschließend im RequestHandler zu landen.

Ich möchte jetzt bestimmte Hook-Points für einen Entwickler angeben.
Falls ich den Begriff Hook-Point hier falsch verwende: Ich verstehe darunter Stellen im Code, in die ein fremder Entwickler Code (via Plugin) einfügen kann.

Ein Hook-Point könnte z.B. im Verification-Handler so aussehen:
Die Standard-Komponente fragt Passwort und User ab. Das ist hartcodiert.
Über einen Hook-Point bringt ein Entwickler nun zusätzlich Komponenten ein, die Uhrzeit, Anzahl an Requests oder eine zusätzliche Authorisierung abfragen.

Der Hook-Point wird dabei so implementiert:
Wie oben beschrieben werden über die Config-Datei und die "Pluginschnittstelle" Objekte nach Uservorgaben instanziiert. Alle so erzeugten Komponenten für die Verifizierung von Useranfragen werden z.B. gegen den Map-Eintrag "Verification" in der Map "Components" gemapped.

"Components" wird dabei jedem durch Plugins erweiterbaren Objekt übergeben.

Das ist das, was ich machen will.
Was brauche ich, um das zu realisieren? Spring IoC oder eine OSGi-Implementierung? Und wie lautet der korrekte Fachbegriff dafür?

Btw. habe ich durch Recherchen noch das Apache Commons Config-Projekt entdeckt.
Scheinbar hat das aber nicht wirklich etwas mit meiner Problemstellung zu tun, oder übersehe ich da etwas?

Ob nachbauen richtig ist?
Naja, nur im kleinen Rahmen höchstens, wegen Grundlagenforschung, in proff. Bereich hat das imho nix verloren, auch wenn es noch einige Teams geben soll die am "Not invented here" Syndrom leiden.

Das war auch nur Ironie meinerseits.
Wozu das Rad neu erfinden, wenn man eines nehmen kann, dass tausendfach erprobt worden ist?

EDIT: Achja, vielleicht sollte ich hier wirklich noch mal darauf hinweisen, dass mir das Konzept von Beans trotz Wikipedia noch nicht so ganz klar ist. Im Moment würde ich sagen, dass ich mit meinem ApplicationObject bereits einen Bean geschaffen habe bzw. die darin enthaltenen Objekte (DAOs, RequestHandler etc.) Beans sind.
Ich bitte hier also um Nachsicht, falls einige Schilderungen gefährlichen Unsinn enthalten sollten.

 

[maki]

Bei der Applikation sind bestimmte Reihen- und Rangfolgen hartcodiert und vorgegeben.

Hört sich nach einem Framework an, da offensichtlich "Inversion Of Control" (IoC) beschrieben wird, dein Framework stellt ein Grundgerüst bereit, "User" (Entwickler die dein Framework nutzen) können durch Vererbung und/oder Konfiguration (Annotationen, XML, Java Code, etc. pp.) eigene Codeteile durch das Framework Ausführung bringen.
Hier der obgligatorische Link zu einem Fowler Artikel den du gelesen haben solltest: Inversion of Control Containers and the Dependency Injection pattern

Was ist es denn für eine App?

Spring oder OSGi?
Kommt darauf an, was du machen möchtest.
Eclipse RCP zB. basiert auf OSGi und bietet bereits so einen ähnlichen Pluginsmechanismus, nur besser *g*
Ansonsten würde ich dir empfehlen zuerst Spring zu erlernen.

 

[Sekundentakt]

Hört sich nach einem Framework an, da offensichtlich "Inversion Of Control" (IoC) beschrieben wird, dein Framework stellt ein Grundgerüst bereit, "User" (Entwickler die dein Framework nutzen) können durch Vererbung und/oder Konfiguration (Annotationen, XML, Java Code, etc. pp.) eigene Codeteile durch das Framework Ausführung bringen.
Hier der obgligatorische Link zu einem Fowler Artikel den du gelesen haben solltest: Inversion of Control Containers and the Dependency Injection pattern

Danke für die Referenz. Die sehe ich mir gleich mal an.

Was ist es denn für eine App?

Die App beschäftigt sich mit Machine Learning. Ich versuche mir durch dieses umfangreiche Terrain einen möglichst vielschichtigen Einstieg in Java EE zu ebnen.

Ansonsten würde ich dir empfehlen zuerst Spring zu erlernen.

Ich muss zugeben, ich hab die gefühlten 50 Seiten Spring IoC-Einstieg noch nicht durchgelesen, sondern nur überflogen. Im Moment habe ich den Eindruck, dass sich das was ich vorhabe, via Spring recht einfach und mit geringem Lernaufwand (8 Stunden sollten reichen?) umsetzen lässt.
Im Moment gehe ich nämlich davon aus, Spring herunterzuladen, als Lib in das Projekt einzubinden und anschließend die im Link gemachten Schilderungen nachzuvollziehen. Falls ich mich irre, wäre eine kleine Vorwarnung an dieser Stelle sehr nett .

Danke!

 

[maki]

Die App beschäftigt sich mit Machine Learning. Ich versuche mir durch dieses umfangreiche Terrain einen möglichst vielschichtigen Einstieg in Java EE zu ebnen.

Ich meinte eher Swing/SWT Desktop oder Webapp, was genau ist denn der JEE Anteil?

Der Artikel ist was Spring betrifft nicht mehr aktuell, da geht es nur um die Konzepte und Alternativen (IoC, DI vs. Lookup, etc. pp.)
Für Spring empfehle ich die offizielle Spring Doku, fang mit den Grundlagen inkl. IoC Modul an, inkl. Annotationen.

Spring braucht übrigens mehr als eine Jar *g*

 

[Sekundentakt]

Für Spring empfehle ich die offizielle Spring Doku, fang mit den Grundlagen inkl. IoC Modul an, inkl. Annotationen.

Danke, ich schaue mir das morgen mal an. Und ich hoffe, ich brauche kein ganzes Jahr, um das Beispiel dort zum Laufen zu kriegen .
GenericXMLApplicationContext sieht nach einer komfortablen Implementierung aus. Die Config-Dateien wollte ich nämlich wenn möglich im Root-Verzeichnis der Anwendung parken.

Ich meinte eher Swing/SWT Desktop oder Webapp, was genau ist denn der JEE Anteil?

Sagen wir mal so: Das ist "egal". Der Grund, weshalb ich die High-Level-Abstraktion in eine einzige Klasse gepackt habe war der, dass ich eine Anwendung schaffen wollte, die ich überall einbetten kann. Im Moment erarbeite ich mir Java EE Grundlagen mit Servlet Containern, falls Dir das hilft.
Das einzige, was diese Klasse hier können muss (grafisch), ist eine XML-Antwort auszugeben.
Was man damit macht, entscheidet derjenige, der die Anwendung einsetzt.

Kurz gesagt ist die Umgebung in der das Ding läuft also sekundär.

Übrigens: Der vorgestellte Artikel mag vielleicht nicht mehr ganz aktuell sein, aber das Problem mit Dependency Injection kenne ich ganz gut. Ich glaube, dass man das durch eine gute Dokumentation wieder wettmachen kann.
Sprich: Einmal komplett skizziert welchen Weg eine Anfrage von Eingang bis Antwort nimmt und dann im Detail welche Funktionen welche Komponente und Methode einnehmen.
In der Regel werden Komponenten als abstract oder als Base-Implementation deklariert.
Wenn man die ausführlich dokumentiert, sollten die Cons von DI doch eigentlich in den Griff zu kriegen sein, oder?

 

[maki]

Sehe die Contra Punkte zu Spring eher marginal, gibt auch Toolingunterstützung, zB. Spring Tool Suite (STS) für die Eclipse IDE und durch Annotationen wird eigentlich kein XML mehr gebraucht, ich bevorzuge eine Mischung, annotiere die zu injizierende Variable (bzw. den Setter), deklariere die Beans in XML.

 

[Empire Phoenix]

hatt mal einen ähnlichen fall wo ich hooks einbauen musste (noch garnet lange her)

da es dabei um eine ressourcen schonende lösung geht habe ich mir ein anderes prinzip überlegt/umgesetzt.

es gibt einen plugin ordner mit unterverzeichnissen für jeden hook.
Mitgeliefert werden interfaces für alle hooks
Ein hook ist dann einfach eine das interface implementierende classe gewesen die man in dem dazugehörigen ordner speichert
Das Pogramm hat beim start den pluginordner durchsucht und alle classen per urlclassloader nachgeladen und dann an den entsprechenden stellen eingebunden. Geht solange deutlich einfacher und schnelle solange A) interfaces die hooks sinnvoll abbilden können
B) Man zugriff auf das Dateisystem hat (sag nur webstart ohne erweiterte rechte)
C) Die Hook/Plugins sich als eine Klasse programmieren lassen ohne verrenkungen.

Ansonsten ist ein richtiges Plugin framework der langfristig bessere weg.