SIMON

So, hab jetzt erstmal den Fix für Issue #74 fertiggestellt und commited.

Leider ist dein Patch sehr umfangreich und passt jetzt nicht mehr so ganz zum aktuellen Source-Stand.

Hab trotzdem mal drüber gesehen und 'n kleines Problemchen entdeckt:

Es ist bisher durchaus möglich ein RemoteObjekt unter mehr als einem Namen in der Registry zu registrieren. Mit dem Lookup via Interface steht man dann vor dem Problem: "Welche Instanz ist jetzt die Relevante?".

Wie ist das mit Spring in dem Fall? Würde es hier Sinn machen einfach nur "die Erstbeste" zu nehmen? Vorschläge?

Weiterer Punkt: MINA 2.0.0 RC1 ist offenbar noch mehr buggy als Milestone6. Zumindest bin ich da auf eine Deadlock-Situation gestoßen die ich bereits in der Mina-Mailingliste angesprochen habe (hab aber noch keine Antwort). Deshalb bis auf weiteres: M6 satt RC1.

Zum Rest:

Hier und da gefällt mir die neue "Ordnung" noch nicht so ganz. Das Dispatcher releasen sollte nach wie vor zentral sein und nicht in "AbstractLookup" liegen. Hintergrund: Ein Dispatcher gibts nicht nur da wo ein Lookup gemacht wird, sondern auf auf Serverseite. Aber gut, das sind Kleinigkeiten.

Den Ansatz mit den unterschiedlichen Lookup Typen finde ich interessant. Ich denke im großen und ganzen werde ich die Idee übernehmen.

Hatte das RC1 auch nur mal reingepackt zum testen, sollte eigentlich nicht mit im Patch liegen hust

Spring schmeisst bei WireByType genau wie meine Interface-Lookup Methode eine NoUniqueBeanException bzw eben hier NoUniqueImplementationException. Will man mit Interface abfragen ist halt kein mehrfaches Binding möglich, alles andere wäre gegen eine saubere Abhängigkeiten-Regelung da niemals verlässlich zu sagen wäre welche Implementierung kommt.

Was eventuell noch interessant wäre wie in OSGi: getAllImplementationsByInterface. So lassen sich in OSGi alle Services zu einem bestimmten Interface ausgeben.

Ich werde den Patch noch mal an den aktuellen Source anpassen und in kleinere Teile aufspalten. Werde mich Morgen mal mit deinen Änderungen auseinandersetzen.

Oh, hab ich da ne Exception übersehen? Aber klar, die passt dann bestens.

Richtige Änderungen gibts hauptsächlich im Protokoll. Der rest ist "code formatting".
Einzelne Patches wären schon geschickter :-)

Gibt es sogar nen extra Unittest für ;-)

Servus,

hab mal ne Frage zu deinem implementierungsvorschlag:

Du hast im Lookup-Interface die lookup() Methode mit Generics versehen.

Irgenwie ergibt das noch keinen richtigen Sinn da nirgendwo der Typ vorgeschrieben wird. Hätte man ja auch gleich "Object" nehmen und Generics weglassen können.

Des weiteren rätsle ich gerade wie man es noch besser machen könnte: Auf der einen Seite ist es schick, wenn man, egal welche create...Lookup() Methode man benutzt, einfach ein Object vom Typ "Lookup" gemäß Interface benutzen kann. Aber der anderen Seite ist es doch sehr unschick, wenn man erst in's JavaDoc schauen muss was man denn nun in die lookup() Methode des generischen Lookup Objects reinfüttern darf und sich das ganze nicht aus der Methodensignatur ergibt.

Die einfachste Lösung wäre für jede create...Lookup() Methode das entsprechende Interface zurück zu geben und so, je nach Verwendung, eine exakt passende Methodensignatur für die lookup() Methode zu haben. Aber dann ist der generische Faktor weg :-(

Hab noch keinen definitiven Plan wie ich das nun mache...

- Alex

Doch definiert ist er noch aber nicht mehr genutzt. Ist ein Überbleibsel von den Tests. Hatte da noch so ein wenig was probiert und wohl vergessen den Typ rauszunehmen.

Abgesehen davon find ich das gar nicht ungünstig. Immerhin hast du dir ja vorher extra die richtige Lookup-Implementierung geholt. Deiner Aussage nach wäre das JDBC API schlecht weil ich erst schauen muss wie der Connection-String für eine entsprechende Datenbank-Implementierung aussieht.

Deiner Aussage nach wäre das JDBC API schlecht weil ich erst schauen muss wie der Connection-String für eine entsprechende Datenbank-Implementierung aussieht.

Naja, das hab ich so direkt nicht gesagt. Das ist deine Schlussfolgerung.
JDBC ist IMHO ein etwas anderes Level als die Lookup-Schnittstelle. Wenn SIMON jetzt nur wie JDBC die API wäre und man einen 3rd-Party Treiber dazulegen müsste um den Lookup zu machen, dann könnte ich dir vollends zustimmen. Aber so trifft's deine Aussage nur zum Teil. Aber ich verstehe was du damit sagen wolltest.

Wie gefällt dir diese Idee:

Wie bei JDBC den gemeinsamen Nenner auf String (statt ein beliebiges Objekt) umstellen. Für den Namens-Lookup wird dann als String der Name des Objekts benutzt, und für den Interface-Lookup wird als String der Name des Interfaces benutzt.

Interfacenamen als Class.getCanonicalName()?

Zum bleistift ...

Okay, im SVN Trunk ist das mit dem Interface-Lookup ja schon ne weile drin. hast du's schon durchgesehen/ausprobiert?

- Alex

Sorry nee hatte ich noch nicht, da ich den SpringRemoting Ansatz erstmal bei Seite geschoben hatte damit du in Ruhe alles umbauen kannst. Werde da auch nochmal ein wenig auf dich zukommen weil es noch andere Punkte gibt wo dieses Utility-Class Verhalten ein wenig schwierig ist und wo ich bisher auf Reflection zurückgegriffen habe um in Simon aufzuräumen (wo man normal keinen Zugriff auf die Funktionen hat :P).

Werd's mir am Wochenende mal ansehen aber ich denke, wenn der Unittest läuft sollte das so funktionieren.