2009-06-20 12 views
7

Po uruchomieniu aplikacji webowej w Tomcat 6.0.18, uruchamiam Spring tylko z tego, co jest konieczne, aby zainicjować system - czyli na razie migracje bazy danych. Nie chcę, aby jakakolwiek część systemu była ładowana, dopóki migracja nie zakończy się pomyślnie. Uniemożliwia to innym fasolom oczekiwanie na zakończenie migracji przed uruchomieniem lub nawet utworzenie instancji.Czy mogę dynamicznie ładować dodatkowe pliki konfiguracyjne Spring do istniejącego obiektu WebApplicationContext?

Mam plik startup-appcontext.xml skonfigurowany za pomocą dbMigrationDAO, menedżera startupManager, który jest ThreadPoolExecutor, a na końcu komponent bean FullSystemLauch. Przekażę listę lokalizacji konfiguracji do fasoli FullSystemLaunch za pomocą zastrzyku ustawiającego. Fasola FullSystemLaunch implementuje ServletContextAware, otrzymuje odniesienie do bieżącego WebApplicationContext, a zatem mogę mieć ConfigurableListableBeanFactory. Niestety, ta fabryka fasoli jestConfigurationFrozen() zwraca true, więc przez wywołanie beanFactory.setConfigLocations (configLocations) nie ma wpływu.

Czy mogę to zrobić, czy też wiosna przeszkadza mi w tym, ponieważ jest to trochę niecodzienne? Wydaje się rozsądne, jeśli jest zrozumiałe, ale także nieco niebezpieczne. I tak, jestem gotów zdmuchnąć aktualny kontekst b/c aktualnie załadowane Singletony nie są potrzebne po zakończeniu inicjalizacji.

Dziękuję za pomoc.

Odpowiedz

2

Można użyć istniejącego kontekstu jako kontekstu macierzystego dla innych kontekstów, chociaż wątpię, aby można było zastąpić istniejący obiekt WebApplicationContext.

Jeśli korzystasz z opakowania EAR-WAR, otrzymasz to gotowe do użycia (rodzaj) poprzez załadowanie kontekstu aplikacji z pliku EAR, a następnie dodanie go do WAR.

Nie wiem, czy ma to zastosowanie w Twojej sytuacji.

0

Czy możliwe jest, aby lazy-initialization było alternatywą dla tego, co próbujesz osiągnąć?

+0

Nie; w każdym z komponentów musi pozostać logika, aby zapobiec inicjacji lub "wykonaniu swojej pracy" przed zainicjalizowaniem systemu. – Elliot

+1

Dlaczego nie po prostu ustawić wszystkie ziarna, aby były leniwe. Następnie utwórz komponent bean właściciela, również zainicjowany w trybie leniwym i dodaj wszystkie pozostałe komponenty bean jako zależności. Po wywołaniu beanContext.getBean ("mybean") zostaną utworzone wszystkie komponenty bean. – kgiannakakis

3

Moja opinia pozwoliłaby Springowi na zainicjowanie twoich fasoli, jeśli uzna to za stosowne - w kolejności zadeklarowanych zależności.

Jeśli potrzebujesz migracje baz danych istnieje kilka wzorów, aby je uruchomić pierwszy:

  • jeśli używasz Hibernate/JPA dokonać SessionFactory/persistenceManager zależeć na ziaren migracji;
  • jeśli używasz zwykłego JDBC stworzyć DataSource otoki iw jego startowe metody powoływać się na migracje (code sample)

Korzyści są oczywiste: prostota.

0

można przebudować WebApplicatonContext na ConfigurableWebApplicationContext , a następnie użyć metody setConfigurations.

Nie zapomnij odświeżyć;

0

Było to to samo zadanie i stworzyłem dwa konteksty: startUpContext.xml i applicationContext.xml.W wersji startUpContext.xml znajduje się komponent bean, który uruchamia ładowanie appliationContext.xml. (lokalizacja kontekstu aplikacji jest skonfigurowana jako startUpContext.xml jako właściwość wyzwalacza). I wreszcie spust zastępuje lokalizacje bieżącego kontekstu i odświeża go:

applicationContext.setConfigLocations(locations); 
applicationContext.refresh(); 

(startUpContext.xml jest ładowany za pomocą standardowego ładowarki kontekstowego wiosna słuchacza)