@Resource oder wie man auch eine einfache Standardisierung suboptimal lösen kann
@Resource ist im Rahmen von
JSR 250 standardisiert. Diese Annotation wird verwendet, um sich Objekte injizieren zu lassen. Eigentlich ganz einfach, sollte man denken. Aber der Standard enthält mehrere Schwächen:
- Normalerweise würde man denken, dass man einfach @Resource("name") schreiben kann. Ist natürlich nicht so: Man muss @Resource(name="name") schreiben.
Man würde auch denken, dass der Standard sagt, dass @Resource einfach etwas mit dem passenden Namen und Typ injiziert - Spring injiziert zum Beispiel Spring-Bean mit dem entsprechenden Namen. Dann würde der Standard nämlich von der zugrundeliegenden DI-Implementierung abstrahieren. Natürlich ist das nicht so: Die Spezifikation sagt explizit, dass es ein Objekt aus dem JNDI sein muss. Also muss eine konforme JSR-250-Implementierung JNDI mitbringen. Spring kann übrigens auch diese Semantik der Annotation unterstützen. Andere Elemente der Annotation, die definieren, wie die Authentication funktioniert, oder ob man die Ressource auch mit anderen Komponenten teilen kann, sind natürlich in einfacheren DI-Umgebungen auch nicht so ohne weiteres nachzuempfinden...
Constructor Dependency Injection ist für die Expert Group offensichtlich ein Fremdwort. Die Annotation ist nur auf Felder und Methoden anwendbar. Wäre sie auch für Parameter gültig, könnte man Constructor Dependency Injection oder auch Methoden mit mehreren Parametern unterstützen - leider ist das aber nicht vorgesehen.
Weil wir gerade bei den erlaubten Zielen der Annotation sind: Wußten Sie, dass man @Resource zum Annotieren von Klassen nutzen kann? Schauen Sie mal in das JavaDoc oder in die Spezifikation, wenn Sie nicht wissen, was das wohl bedeuten mag.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
