Brainstorming: Wohin mit der @SimonRemote Annotation

Hallo zusammen,

muss mal wieder meine Gedanken zu (virtuellem) Papier bringen...
Es geht um das Annotation-Feature der kommenden 1.1.0 Version von SIMON.

Bis dato musste man ja ein Interface schreiben das von "SimonRemote" erbt. Das musste man dann implementieren und eine Instanz dieser Klasse dann in der Registry anmelden.

Aktuell gibts schon die Möglickeit mit Annotations zu arbeiten. Das erspart einem das "extends SimonRemote" in der Interface-Klasse und man kann bequem das Interface von eigenen Dingen erben lassen.

Ich rätsle gerade wo man jetzt am besten die Annotation "@SimonRemote" hinpackt. Ins Interface? In die Implementierung? In beides?
Bin mir da etwas unschlüssig. Tendiere aber eher zur Implementierung statt zum Interface. Denn eventuell hab ich ja ein Interface das ich nicht beeinflussen kann oder darf. Dann wäre es in der Implementierung besser aufgehoben.

Aber woher weiß ich dann welche Methoden Remote sind und welche nicht?! Muss ich das wissen?
Im JEE Umfeld gibts solche Annotationen:

@Stateless
@LocalBinding(jndiBinding = IMyClass._BIND_NAME_)
@RemoteBinding(jndiBinding = IMyClassHelper._BIND_NAME_)
@Remote (IMyClassHelper.class)
@Local(IMyClass.class)
public class MyClass { ... }

Die Binding- und Stateless-Annotation sind hier ohne Container wohl nutzlos. Bleiben die noch die @Remote und @Local Annoatations. Local brauchen wir auch nicht. Bleibt noch @Remote

Da gibt man an gemäß welchem Interface exportiert werden soll. Auf SIMON abgebildet könnte das so aussehen:

@SimonRemote (MyRemoteInterface.class)
public class MyRemoteImpl extends MyRemoteInterface { ... }

MyRemoteInterface wäre hierbei befreit von allen abhängigkeiten zu SIMON. Es spielt dann keine Rolle mehr ob man einfluss auf das Interface hat, oder ob man es vorgegeben bekommt.

Ideen? Gegenvorschläge? Diskussionen bitte ...

- Alex

Replies (3)

RE: Brainstorming: Wohin mit der @SimonRemote Annotation - Added by Noctarius about 2 years ago

Ich würde, genau wie du, dazu tendieren die eigentliche Implementierung zu annotieren. So machen es auch andere große Vertreter, wie z.B. Spring. Alternativ könnte man einfach beides zulassen.
Es ist übrigens kein Problem wenn das Annotation beim Laden der Klasse ohne Simon im Classpath, da in Java Annotations so definiert sind, dass sie einfach (beim Laden) übersprungen werden, wenn die Klasse dazu nicht existiert (es fliegt also keine ClassNotFoundException).

Allerdings bin ich mir noch nicht ganz sicher, wieso du das Interface-Class angibst. Dieses würde ich (wenn schon) entweder als Class-Array machen, damit ich auch mehrere Interfaces gleichzeitig exportieren kann oder eben weiterhin aus der Implementierung ziehen.

Dabei würde ich erst schauen ob in der Annotation Interfaces (Class[]) angegeben sind und wenn nicht die Interfaces aus der Implementierung übernehmen.

RE: Brainstorming: Wohin mit der @SimonRemote Annotation - Added by achristian about 2 years ago

So, bin mittlerweile wieder aus dem Urlaub zurück und hab im Geschäft das wichtigste aufgearbeitet... Hab nun wieder etwas Zeit für SIMON ;-)

Ich würde, genau wie du, dazu tendieren die eigentliche Implementierung zu annotieren. So machen es auch andere große Vertreter, wie z.B. Spring. Alternativ könnte man einfach beides zulassen. Es ist übrigens kein Problem wenn das Annotation beim Laden der Klasse ohne Simon im Classpath, da in Java Annotations so definiert sind, dass sie einfach (beim Laden) übersprungen werden, wenn die Klasse dazu nicht existiert (es fliegt also keine ClassNotFoundException).

Super. Freut mich ;-)

Allerdings bin ich mir noch nicht ganz sicher, wieso du das Interface-Class angibst. Dieses würde ich (wenn schon) entweder als Class-Array machen, damit ich auch mehrere Interfaces gleichzeitig exportieren kann oder eben weiterhin aus der Implementierung ziehen.

Naja. Wenn man kein Interface angibt, dann gibts nur eine Lösung: Alle Interfaces exportieren. Und das ist vielleicht nicht unbedingt "praktisch".
Das Beispiel sollte nur exemplarisch die Möglichkeit zeigen. Klar. Nur ein einzelnes Interface angeben können wäre doof. Ein Array ist da doch schon praktisch.

Dabei würde ich erst schauen ob in der Annotation Interfaces (Class[]) angegeben sind und wenn nicht die Interfaces aus der Implementierung übernehmen.

Klar. Das wäre meine Fallback-Strategie gewesen. Wenn man nur ein einziges Interface hat wäre es ja umständlich auch das noch explizit für den Export angeben zu müssen. Von daher sollten beide Möglichkeiten unterstützt werden.

Weitere Vorschläge? Anregungen?

- Alex

RE: Brainstorming: Wohin mit der @SimonRemote Annotation - Added by achristian about 2 years ago

So, hab das mal so implementiert. Muss aus der "Ausprobierklasse" noch nen Unitest formen. Aber soweit klappt's schon prima. War ja auch nicht weiter aufwendig.

- Alex

update
Kommando zurück

Ist noch ein Bug drin. Mit angabe der Interfaces in der Annotationm geht's schon. Ohne angabe noch nicht ;-(

update
So, jetzt geht's

(1-3/3)