Wer in Spring-Konfigurationen seiner Anwendung Beans als Singletons definiert, sollte sich darüber im Klaren sein, dass er mit diesem Bean-Scope keine Umsetzung des Singleton-Entwurfsmusters der Gang of Four erreicht.
Eine Spring Bean, die mit dem Singleton-Scope versehen wurde (default-Konfiguration), ist lediglich im Kontext einer IOC-Container-Instanz einzigartig. D.h. dass es durchaus mehrere Instanzen einer solchen Singleton Bean geben kann. Nämlich genau dann, wenn man sich mehrere IOC-Container-Instanzen in Form von ApplicationContext-Instanzen erzeugt. Jede dieser Instanzen verwaltet dann ihre eigenen Beans.
Ein Verständnis dieses Konzepts hilft dabei, schwierig aufzufindende Fehler zu vermeiden.
Möchte man zum Beispiel in seiner Anwendung an irgendeiner Stelle Zugriff auf eine Spring Bean haben und diesen nicht per Dependency Injection ermöglichen, so muss man sich den Zugriff mit Hilfe einer ApplicationContext-Instanz verschaffen. Erstellt man sich nun aber diese Instanz zum Beispiel mittels
new ClassPathXmlApplicationContext(path); |
dann muss man beachten, dass damit eine neue IOC-Container-Instanz erzeugt wird, deren Singleton Beans nicht die sind, die von der Anwendung für die Dependency Injection verwendet werden. Denn hierfür wird eine IOC-Instanz benutzt, die beim Anwendungsstart generiert wird.
Definiert man nun zum Beispiel Beans, die eine Datenbankverbindung erzeugen, so führt die gerade beschriebene Art und Weise der Zugriffsverschaffung auf diese Beans dazu, dass mit jeder ApplicationContext-Instanz auch jeweils neue Verbindungen geöffnet werden, bis es irgendwann zu viele für den Datenbank Server sind.
Es ist ratsam, Spring Bean Instanzen nur per Dependency Injection zur Verfügung zu stellen. Falls dies nicht möglich ist, so sollte man sich bemühen, die in seiner Anwendung bereits automatisch erzeugte und benutzte ApplicationContext-Instanz zu verwenden. Dies ist bei Web-Anwendungen zum Beispiel möglich durch:
ContextLoader.getCurrentWebApplicationContext(); |
