wielokrotne uzycie applicationContext

Czesc, mam takie pytanie - jak prawidlowo uzywac applicationContext w roznych klasach aplikacji?
Tzn. uzywam applicationContext by wczytywac DAO:

//w klasie A
    private final ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

//pozniej w metodzie test() klasy A:

            TestDAOImpl testImpl = (TestDAOImpl) context.getBean("testDAOImpl");
            TestBean testBean = new TestBean(1, 2, 3);
            testImpl.updateTestBean(testBean);

 

zas w applicationContext.xml jest to zdefiniowane:

	<bean id="testDAOImpl" class="com.test.db.dao.TestDAOImpl">
		<property name="sessionFactory" ref="hibernateSessionFactory" />
	</bean>
 

i to jest ok. Mam w ten sposob dostep do DAO Test'a w klasie A. Ale teraz mam sobie klase B i znow potrzebuje dostepu do DAO Test'a. Potrzebuje wiec znow miec:

private final ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

Tylko ze to mi chyba wczyta jeszcze raz, prawda? A czy to nie powinno byc tak (nie wiem, dlatego pytam) ze raz to sobie wczytam a potem we wszystkich klasach mam dostep do context przy pomocy jakiejs mojej metody typu getMyContext()?
Jak ja powinnam to poprawnie zrobic?

1. Moze stworzyc sobie Singleton ktory raz wczyta tego xml'a a potem wlasnie bedzie zwracal dostep do niego poprzez metode typu getMyContext()?

2. Moze to jest jednak poprawne ze w kazdej klasie w ktorej potrzebuje wywoluje na nowo:

   private final ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
 

aby uzyskac dostep do context?

3. A moze to sie robi w jakis inny(odpowiedni) sposob (jaki?)

Pytam poniewaz chce tego uzywac poprawnie, szukam w googlach ale widze rozne podjescia, a chcialabym miec pewnosc ze uzywam tego najbardziej odpowiednio jak sie da - stad prosba o rade do Was!

       pzdr,
       misty

Szukajac w google, zainteresowal mnie pattern z ApplicationContextProvider:

 
public class ApplicationContextProvider implements ApplicationContextAware {

    private static ApplicationContext context;

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        System.out.println("SET");
        this.context = applicationContext;
    }

    public static Object getBean(String name) {
        return context.getBean(name);
    }

w applicationContext.xml:

 	<bean id="applicationContextProvider" class="com.test.configuration.ApplicationContextProvider" />

I teoretycznie dalej w programie powinnam miec dostep poprzez:
ApplicationContextProvider.getBean("name");

tzn tak ja to rozumiem to podczas inicjalizacji powinna zostac wywolana metoda "set", powinno byc to wstrzykiniete. Tak przynajmniej tlumacza i pokazuja wszystkie przyklady. Niestety to mi rzuca NullPointerException, metoda set nigdy nie jest wykonana. Czy ktos z Was umialby wskazac czemu?

 pzdr,
      misty

Zauwazylam ze jak wczesniej dodam normalne wczytanie konfiguracji:

ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

To metoda set jest wywolana. Ale to jest troche bez sensu (albo ja to zle kumam). Ja myslalam ze za mnie to spring zrobi. A skoro mam sama wczytywac te konfiguracje to w ogole jaki jest sens korzystania z tego interfejsu?

pzdr

Nie powinnas musiec sama szukac beanow w applicationContext - wstrzykuj je. Zobacz sobie np. SpringJunit4TestRunner lub inne - tam tworzysz test, dodajesz anotacje, runner tworzy kontekst, a ty tylko wstrzykujesz beany jak w normalnych klasach.

Czesc,
dzieki za odpowiedz!

Nie bardzo kumam. A jakoze google nie zawalil mnie stosem linkow dotyczacych SpringJUnit4TestRunner(przynamniej nie na tyle zrozumialych na moja glowe) to chyba bede zmuszona zadac Ci jeszcze pare pytan.
Po pierwsze - nazwa mi wskazuje ze to chyba powinnam uruchamiac podczas testow (zgaduje, bo nie wiem). A nie o to mi przeciez chodzi. No wiec dalej nie wiem jaka byla Twoja mysl :/

pzdr,
misty

@misty bo uruchamiasz sobie to jako taka standalone'ową aplikację i stąd problem. Spring robi wstrzyknięcia automatycznie wczytując kontekst ale tylko jeśli aplikacja jest uruchamiana przez kontener IoC. W tym przypadku tak nie jest, więc kontekst musisz wczytać ręcznie. Musisz poszukać jak uruchomić testy poprzez Springa.

Sory, myslalem ze chodzi ci o testy, bo mowisz o jakichs testowych metodach.
Wiec ogolnie wyglada to tak: uzywanie kontekstu w aplikacji to wielkie no-no i antywzorzec - powinnas uzywac wstrzykiwania. Wyjatkiem jest bootstrapping, no bo ktos gdzies ten poczatkowy kontekst i obiekty musi otworzyc. W aplikacjach webowych robi to jakis web context listener. Jesli Shalom ma racje i uruchamiasz jakas standalone aplikacje, to musisz to zrobic ty. Robi sie to wlasnie tak, ze tworzysz instancje kontekstu, pobierasz z niego jakies poczatkowe beany, przekazujesz dalej do metody main, wolasz metode i reszta fruwa sama. Te pierwsze beany ktore pobierasz ze springa beda przez spring mialy wykonane wstrzykiwanie zaleznosci; te zaleznosci rowniez beda mialy wstrzykiwane zaleznosci itp., rekursywnie. Z tego wynika, ze beany ktore pobierasz raz z kontekstu inicjalizuja wszystko i juz.
Architektura: jakies twoje klasy korzystaja z DAO, wiec skonfiguruj te klasy w xml springowym aby mialy te dao wstrzykniete. Z kolei te klasy sa zaleznosciami jakichs innych klas, te znowu jakichs innych, i tak w kolo macieju az dojdziesz do beanow top-level, ktore przekazujesz metodzie main czy komus innemu. Tak to sie powinno robic. Wiadomo, czasami trzeba jawnie skorzystac z kontekstu, ale to wtedy sprobuj zrobi tak, aby beany byly contextAware, i beda mialy kontekst wstrzykniety w czasie tworzenia. Takie statyczne metody dajace kontekst itp. to wielki wrog testowalnosci.

Sorki, wprowadzilam Was w blad poprzez to "test". Nie chodzi mi o testy. I tak, jest to aplikacja stand-alone. To teraz mi sie rozjasnilo juz troche. Jakos bylam pewna ze aplikacja sama powinna wiedziec ze ma korzystac z applicationContext.xml skoro uzywam tego interfejsu ApplicationContextAware. A wyglada na to ze tak nie jest. Ja ogolnie wczesniej mialam tak, ze w mojej klasie ktora robi glowna logike zdefiniowalam sobie:

private final ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

i potem w miejscach w ktorych potrzebowalam miec dostep do moch dao (ktore zdefiniowalam w applicationContext.xml) to mi wystarczalo bo korzystalam pozniej z context.getBean(name). Problem mi sie pojawil jak chcialam miec do nich dostep w innej klasie (tzn do tych dao) i zaczelam sie zastanawiac czy kolejna inicjalizacja

private final ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
w tej drugiej klasie jest poprawna. Pewnie nie, bo po co to drugi raz tworzyc? No i tak trafilam na ten pattern (chociaz to w sumie chyba nie jest pattern?) z ApplicationContextAware. Teraz mam tak ze stworzylam sobie klase:

 public class ApplicationContextProvider implements ApplicationContextAware {

    private static ApplicationContext context;

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        context = applicationContext;
    }

    public static Object getBean(String name) {
        return context.getBean(name);
    }

}

Ja to sobie wyobrazam ze to dziala jak Singleton. Raz sie utworzy, nie wiecej i wszedzie mam teraz dostep do tych moich dao poprzez statyczna metode getBean. Problemem bylo to, ze ta metoda setApplicationContext sie nie wywolywala. Myslalam ze skoro to definiuje w applicationContext.xml:

 	<bean id="applicationContextProvider" class="com.configuration.ApplicationContextProvider" />

to automatycznie to robi juz tego seta. Co bylo glupim mysleniem z mojej str bo w ogole co mialoby mi wskazac na ten applicationContext.xml? Teraz po prostu na poczatku programu wywoluje:

new ClassPathXmlApplicationContext("applicationContext.xml");

i jest ok, tzn to mi wywoluje tego seta, wiec pozniej z kazdej klasy w programie moge korzystac z ApplicationContextProvider.getBean(beanName).
I mam nadzieje ze w moim przypadku (aplikacja stand-alone ktore wykorzystuje tylko pare elementow springa) jest to poprawne wywolanie i wykorzystanie.

pzdr,

 misty

Bedzie dzialac, ale to jest zle podejscie - jak napisalem, masz statyczna metode ktora magicznie daje dostep do getBean kazdemu. Chodzi o to ze w poprawnie, zgodnie z kanonami napisanej aplikacji nie masz sama wolac getBean poza bootstrappingiem i jakimis szczegolnymi przypadkami. Twoje DAO nie sa tak szczegolne. Droga ktora idziesz zaprowadzi cie do celu, ale jest dosc pokretna.

hej,
nie wydaje mi sie zeby ta droga byla pokretna, wydaje mi sie dosc prosta i oczywista. Ale fakt-spytalam Was o rady po to by miec to zrobione wlasciwie. Czyli Tobie chodzi o to, bym gdzies na poczatku aplikacji wczytala applicationContext.xml (np poprzez new ClassPathXmlApplicationContext("applicationContext.xml");), a potem sobie wstrzykiwala potrzebne mi DAO w miejscach w ktore chce? Dobrze rozumiem?

   pzdr,
            misty

po to masz springa i DI aby nie wiązać ze sobą obiektów. nie powinno Cie interesować czy coś jest w kontekście a już na pewno nie jak wyciągać z niego obiekty (jaki w tedy jest sens korzystania ze springa/DI - sam zapis getBean wygląda źle) a już na pewno nie powinno Cie interesować że jakiś kontekst istnieje kiedy operujesz na dao.
Masz adnotacje @Autowire, poczytaj o tym, ew. CDI - bo spring nie wszędzie jest z tym zgodny.
jak nie wiesz jak korzystać z DI(autowire) w testach -> dokumentacja springa dokładnie wyjaśnia jak tworzyć kontekst i jak wstrzykiwać beany do klas testowych (bodajże 9 albo 10 rozdział w dokumentacji -cały poświęcony testowaniu :D)

Ale to jest aplikacja j2se - czy ja moge tego tutaj sprobowac uzyc?

Ogolnie chyba troche nie kumam. Bo kazdy przyklad jaki przegladam i tak predzej czy pozniej sprowadza sie do tego co ja mam:

ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
	MyTestDAOImpl test = (MyTestDAOImpl )context
				.getBean("myTestDAOImpl ");

 

No wlasnie - to sa tylko przyklady, tutorialki, ktorych w necie mnostwo, z ktorych wiekszosc jest skrotowa i glupia.
Rob jak uwazasz, ja sie wypowiedzialem, moze ktos inny sie wypowie.
Zadaj sobie tylko takie pytanie: skoro w klasach chcesz wolac getBean, to po cholere jakis framework? Lepiej trzaskaj tam new CostamDao albo cos, bedzie i tak lepiej testowalne niz jakis statyczny kontekst. Powinno ci to dac do myslenia.

dokładnie po co używać frameworka który w dużej mierze służy do DI żeby odwoływać się do tego ręcznie?
wstrzykiwanie w springu nie musi być wyłącznie podczas wczytywania kontextu - można ręcznie wstrzykiwać, stąd nawet jak jest problem z desktopem to lepszym rozwiązaniem byłaby fabryka komponentów ui która będzie wykonywać wstrzykiwanie(wtedy mamy odwołanie do kontextu tylko w jednym miejscu), ale to już kwestia czy chce się robić coś większego.

hej!
Oczywiscie probuje rozgryzc to @Autowired, ogolnie z tego co wyczytalam to nie jest jakies mocno skomplikowane. Niestety moje dao jest null! Dodalam do applicationContext.xml:

<bean 
class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

 

to moje dao jest w zdefiniowane w nastepujacy sposob:

	<bean id="testDAOImpl" class="com.test.db.dao.TestDAOImpl">
		<property name="sessionFactory" ref="hibernateSessionFactory" />
	</bean>
 

i pozniej w klasie w ktorej potrzebuje skorzystac z tego DAOImpl:

 
    @Autowired
    @Qualifier("testDAOImpl")
    private TestDAOImpl testDAOImpl;

No i niestety ciagle testDAOImpl jest null! Probowalam tez przez settera:

@Autowired
public void setTestDAOImpl(TestDAOImpl testDAOImpl){
testDAOImpl = testDAOImpl;
}
 

i tez null! Probowalam rowniez poprzez dodanie do applicationContext.xml:

 
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
	http://www.springframework.org/schema/context
	http://www.springframework.org/schema/context/spring-context-2.5.xsd">
 
	<context:annotation-config />

i ciagle null. To ja juz nie wiem.

A po co ten Qualifier w pierwszym przykladzie?

W drugim:

@Autowired
public void setTestDAOImpl(TestDAOImpl testDAOImpl){
testDAOImpl = testDAOImpl;
}
</java>
linijka przypisania wyglada podejrzanie - przypisujesz parametrowi samego siebie, pole this.testDAOImpl pozostawiajac null na wieki wiekow.

Zalecam upgrade do najnowszego springa, wersja 3.1.costam, poprawili i usprawnili wstrzykiwanie za pomoca adnotacji i wiele innych bledow.

No to Qualifier to uzylam juz w n-tej probie - myslalam ze pomoze jak podam nazwe z configa (bo tak to chyba dziala, prawda?).

 
@Autowired
public void setTestDAOImpl(TestDAOImpl testDAOImpl){
System.out.println("JESTEM");

this.testDAOImpl = testDAOImpl;
}

dzieki za uwage, ale z "this" tez nie dziala. W ogole sie ten setter nie wywoluje - nie dostaje na konsole "JESTEM". Dodalam jeszcze w applicationContext:

	<context:component-scan base-package="com.test" />
 

ale tez nic. Nie kapuje. Jak zmusic by sie ten setter wykonal? Poza tym - przez setter to tylko jeden ze sposobow. Dlaczego nie dziala mi rowniez:

 
@Autowired
private TestDAOImpl testDAOImpl;

przeciez powinno dzialac.. Bo rozumiem ze sama klasa TestDAOImpl nie powinna miec zadnych adnotacji? tzn nie musi miec nic extra?

@Shalom

Tak! W ogole to sciagnelam z neta dzialajacy przyklad, ale widze ze aby dzialal to wpierw i tak musze sie raz odwolac poprzez getBean. Wyglada to tak:

w applicationContext.xml:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

	<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />

//....

	<bean id="customer" class="com.mkyong.common.Customer">
		<property name="action" value="buy" />
		<property name="type" value="1" />
	</bean>

	<bean id="personA" class="com.mkyong.common.Person">
		<property name="name" value="mkyongA" />
	</bean>


//to jest wyciagniety z mojej aplikacji bean. w tej dzialajacej aplikacji chcialam go przetestowac
	<bean id="testDAOImpl" class="com.mkyong.common.TestDAOImpl">
		<property name="sessionFactory" ref="hibernateSessionFactory" />
	</bean>

 

I teraz klasa main:

public class App {
    
    
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext(
				"applicationContext.xml");
		
		Test test = new Test();
		test.doTest();
	}
} 

Zas klasa Test:

 
public class Test {

    @Autowired
    private testDAOImpl testDAOImpl;

    public Test() {

    }

    public void doTest() {

        if (testDAOImpl == null) {
            System.out.println("NULL");
        } else {
            System.out.println("NIE NULL");
        }

    }

}

I co? NULL! A kiedy nie dostane nulla? jak np zrobie wg sciagnietego przykladu:

 
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext(
				"applicationContext.xml");
		
		Customer cust = (Customer) context.getBean("customer");
		System.out.println(cust);
	}

i teraz w tym Customer ktory jest wpierw wczytany poprzez getBean, dodam

 @Autowired
private TestDAOImpl testDAOImpl;

to nie bedzie on nullem! Totalnie juz teraz nie kapuje!

Widocznie Spring używa leniwej inicjalizacji -> póki ktoś się nie odwoła do jakiegoś beana to nie następuje ich tworzenie (co jest nawet dość logiczne).

Ale co ma piernik do wiatraka? Przeciez ja sie odwoluje do obiektu! Tylko jesli nie wczytam wczesniej jakiegos bean poprzez getContext to ten moj testDAOImpl jest nullem. Zreszta lazy-init=false tez nic nie pomaga.

Spojrz - jak dam w maine:

ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
Test test = new Test();
test.doTest();
 

gdzie klasa Test:

 public class Test {

    @Autowired(required=true)
    private TestDAOImpl testDAOImpl;

    public Test() {
    }

    public void doTest() {

        if (testDAOImpl == null) {
            System.out.println("NULL");
        } else {
            System.out.println("NIE NULL");
        }

    }

}

To mam NULL.
Ale jak juz wrzucilam Test'a do applicationContext i wczytalam go poprzez getBean:

 		<bean id="test" class="com.mkyong.common.Test">

	</bean>

main:

 	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext(
				"applicationContext.xml");
		
		Test test = (Test)context.getBean("test");
		test.doTest();
}

to juz nie mam nulla! Troche to chyba bez sensu?

Ale czemu bez sensu? Spring widocznie zakłada ze dopóki nie zrobisz getBean() to nie korzystasz z beanów i nie ma sensu ich tworzyć, a ty sobie tutaj mieszasz DI ze zwykłym tworzeniem obiektów i stąd problem. Zresztą wstrzykiwanie powinno być wykorzystywane do składania pewnej hierarchii obiektów - do inicjalizacji, a nie do częściowego tworzenia obiektów (no bo inaczej tego co robisz nazwać nie można - u ciebie Spring zajmuje się dostarczaniem części zależności do obiektów tworzonych w runtime)

Nie wiem czy od poczatku czytales ten watek, ale sprawa rozchodzila sie o to jak mam korzystac z moich obiektow ktore sa implemntacja DAO.
Wiekszosc mojej poprzednia rozmowy z chlopakami tyczyla sie tego, ze korzystam z nich wlasnie poprzez getBean i ze to jest zle. Zasugerowali mi ze powinnam skorzystac z DI. Moja klasa ktora w wiekszosci korzysta z tych DAO beanem nie jest. Teraz mam druga klase (ktora tez beanem nie jest) ktora potrzebuje skorzystac z DAO. Mi sie rozchodzilo o to - jak ja powinnam z tego poprawnie korzystac? Bo przeciez nie bede w kazdej klasie wczytywac contextu. Stad wzial sie pomysl na skorzystanie z ApplicationContextAware - to mi zalatwialo sprawe bo czytalam context tylko raz(na poczatku programu), a potem w kazdym miejscu mialam dostep do DAO, ale wlasnie poprzez getBean. Co jest ogolnie ponoc slabym rozwiazaniem - stad chcialam uzyc @Autowire. Ale teraz to juz serio - po prostu nie kumam. To jak ja moge wstrzyknac sobie moje DAO do klasy ktora go potrzebuje (ktora bean nie jest) bez tworzenia jej jako getBean?
Czy to totalnie nie jest tak i mieszam juz tak strasznie?

pzdr,
misty

Tak, strasznie mieszasz. Polecam usiasc na spokojnie, i przeczytac dokumentacje kontenera DI w springu, jak sie go uzywa, rodzaje konfiguracji. Odradzam latanie po Google i roznorakich linkach ktore tam znajdziesz, kopiowania przykladow, modyfikowania ich i wkurzania sie ze nie dziala - przeciez nie rozumiesz podstaw i zasad DI, ani tej szczegolnej implementacji (Spring DI).
Przeczytaj, zrozum, uzywaj.

Ok, sprobuje zaczac od nowa. Co do dokumentacji Springa - nie to ze nie probowalam. Ale ciezko jest przez to przejsc. Brakuje tutoriala "podstawowej wiedzy w pigulce". Cala dokumentacja jest mozolna, dluga i momentami chce sie spac. Dlatego sie z nia w koncu poddalam. Ale ok, jak sie nie da inaczej to musze tam wrocic.

http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/beans.html

Przeczytaj to, powinno wiele wyjasnic. Po przeczytaniu i zrozumieniu wracasz na forum i zadajesz konkretne pytania, znajac terminologie i zasady dzialania, co ulatwi wszystkim zadanie.

No dobra.. sporo sie rozjasnilo, ale nie ukrywam ze jednak nie wszystko. Mam jednak nadzieje ze tym razem moje pytania beda sensowniejsze i da sie na nie odpowiedziec:

1. Dla jakiegos bean'a zdefiniowac sobie moge zestaw obiektow o jakis wartosciach - ktore beda mi potrzebne, np:

	<bean id="test" class="com.mkyong.common.Test">
		<property name="testDAOImpl" ref="testDAOImpl" />
		<property name="val" value="8" />
	</bean> 

2. Wlasnie - ta klasa w ktorej chce miec (np) @Autowired musi byc beanem, prawda? tzn musi byc zarejestrowana w applicationContext jako bean. A ja myslalam ze nie musi. Ja mam sobie klase X ktora dziala na zasadzie TimerTask'a - i to wlasnie w niej potrzebne sa mi te moje DAOImpl. Ale ja nie widze tego zeby X definiowac jako bean. tzn moze mam zle wyobrazenie, moze jednak klasa a'la TimerTask moze byc beanem i potem w jej properties moge sobie zdefiniowac te moje DAOImpl i inne bajery ktore beda sobie chciala dac @Autowired i z nich korzystac w tej klasie, i jest to zgodne ze wszystkimi kanonami?
   Ta moja klasa X jest na tyle prosta, ze nie ma sensu dopisywac tu jeszcze jakiejs warstwy serwisow - bedzie to na prawde przerost formy nad trescia. U mnie przychodzi zdarzenie A - to wywolaj na testDAOImpl.update albo przychodzi zdarzenie B to wywolaj na test2DAOImpl.update.
   Co Ty na to?

3. No i najwazniejsza sprawa ktora sprawia mi tu problem (a na ktora nie odnalazlam odpowiedzi lub po prostu nie skumalam) - jest ciagle kwestia tego jak zaczac?
   Skoro juz definuje tego mojego Test'a jako bean, ustawiam mu te property, w klasie Test definiuje odpowiednie settery - to tak na prawde by zainicjalizowac wartosci dla val oraz testDAOImpl nie moge napisac po prostu:

Test test = new Test ()//chociaz to spowoduje mi wywolanie setterow!

tylko musze jednak:

Test test = (Test)context.getBean("test");

i tak jest rowniez w tej dokumentacji, ja nadal nie znalazlam innego sposobu. W sensie ze moj "pierwotny" bean (w ktorym bede korzystac ze wstrzykiwania) musi byc zainicjalizowany wlasnie przez to getBean, prawda? I potem w nim moge sobie juz operowac na wszystkim co dla niego ustawilam w context jako property - tzn w nim sobie wstrzykuje?

pzdr,
misty

przejżyj sobie, bardzo prosty przykład. (Maven, odpal sobie App.main)

Akurat w takim przypadku problemem są komponenty swinga - nie ma za bardzo hooków aby wstrzykiwać zależności, dlatego wspomniałem o fabryce komponentów.

Jak chcesz tworzyć beany to korzystyasz z kilku adnotacji springa (service, komponent, reposity id) a następnie mówisz kontekstowi jakie pakiety ma przeszukać - w ten sposób unikasz klepania xmla który w dużych ilościach jest be.

Zajrzyj jak są wstrzyknięte beany do jpanela - potraktuj to jako pomysł do wspomnianej fabryki.

Nawet jeśli się nie spodoba przykład, to lepiej napisać sobie klasę abstrakcyjną która w konstruktorze będzie wstrzykiwać beany, więc już w klasach dziedziczących można się "cieszyć" di.

No i oczywiście tam wszystko na interfejsach powinno działać,
Jako timer task możesz sobie poczytać pakietach quartz ze springa

Fajny przyklad, dzieki! Potestowalam sobie troche i w MessageFactory, w metodzie init wcale nie musze sie odwolywac do getBeans. Dziala mi @Autowired, czyli mam wstrzyknietego beana bez jego definicji, bez uzycia getBean. Dzieki, o to mi chodzilo!

pzdr,
misty

Ja tylko podpytam dalej tak z ciekawosci, moze ktos podrzucic w ktorym miejscu w aplikacji webowej jest niejawnie wywolywany .getBean(). Tak sobie mysle czy ktos procz mnie sie nad tym zastanawial kiedys :)