[Java] Spring context

[Verwijderd]

Beste tweakers,

Vanuit mijn webapplicatie die draait op tomcat wil ik mijn spring context aanroepen in een bean.
Nu heb ik mijn web.xml als volgt geconfigureerd:

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>resources/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>

Hoe krijg ik nu in mijn bean de context te pakken?

Bedankt!

[redfox314]

Heb je daar die context loader listener voor nodig? Die listener dient om te reageren op events in de lifecycle van de servlet. Volgens mij kan je daar helemaal geen springcontext mee verkrijgen.


Je kan wel de interface org.springframework.context.ApplicationContextAware implementeren en je bean gewoon declareren en spring injecteerd voor jou de application context.
Dit was nu wel de eerste hit in google op use spring context in bean.
Je houd dan gewoon een veld van het type org.springframework.context.ApplicationContext
bij.

[Creepy]

En wat heb je zelf al geprobeerd of gevonden? Wat lukte daar dan niet mee? Kreeg je foutmelding? Zo ja, welke? Zie ook Programming Beleid en dan met name Programming Beleid - De Quickstart. Je probleem dumpen en direct om een oplossing vragen zonder zelf al bezig te zijn geweest is hier niet de bedoeling.

[Daventry]

De ContextLoaderListener gaat er voor zorgen dat hij bij het starten van je applicatie ook de application contexts die je gedefinieerd hebt als value voor contextConfigLocation gaat inladen (resources/applicationContext.xml dus).

Normaal laadt ie enkel XXX-servlet.xml in je WEB-INF (waarbij XXX de servlet-name is die je aan je DispatcherServlet hebt gegeven). An sich heeft dat dus niets te maken met het ophalen van contexten in beans.

Ik vraag me trouwens af waarom je per sé je context nodig hebt in je beans. Als het is om vervolgens een getBean() of iets dergelijks te lanceren, zijn er waarschijnlijk betere oplossingen (injecteren).

[Standeman]

Met ^^
Ik zie even niet in waarom je een context in je bean wilt hebben. Een groot voordeel van Spring is dat het geen impact heeft op je business code (je hoeft niets te overerven of te implementeren om Spring te gebruiken). Hierdoor wordt je Spring afhankelijk en ik neem aan dat je dat niet wilt!

[redfox314]

Je kan ook presentatie laag beans hebben. Die kunnen miss wel de context nodig hebben. (zie dat wel niet zo veel voorkomen gewoonlijk is het een symptoom van slecht design)

[Verwijderd]

Beste tweakers,

Mijn gestelde vraag is te onduidelijk! In mijn applicatie gebruik ik JSF voor de front-end, vanuit een managed bean(JSF) wil ik een spring bean (service) aanroepen op wat gegeven op te halen.

Om dan de getBean functie te gebruiken heb ik een context nodig, of kan ik het beter op een andere manier oplossen?

[Verwijderd]

Standeman schreef op vrijdag 28 maart 2008 @ 08:59:
Hierdoor wordt je Spring afhankelijk en ik neem aan dat je dat niet wilt!

Ik vind dat dergelijke argumenten doorgaans veel te zwaar worden gewogen (niet persoonlijk dus, maar algemeen). Als je Spring toch al in je project hebt zitten, waarom er dan gewoon niet gebruik van maken. Wil ik bijvoorbeeld de interface InitializingBean vermijden omdat ik anders mezelf te veel verbind aan Spring? Moet ik dan een eigen soortgelijke interface maken of afspraken maken hoe mijn eigen initialisatie methode heet? Dat is simpelweg het wiel opnieuw uitvinden. De frameworks zijn er, de code is er, dus maak er ook alsjeblieft gebruik van.

De kans dat je halverwege het project een compleet framework eruit gooit is vrij klein en de inspanning om dan alsnog te refactoren is nihil. En mocht je dat toch willen doen, heb je dan niet een grove inschattingsfout gemaakt bij de keuze van je frameworks?

Ik heb het vermoeden dat het vermijden van afhankelijkheden is voortgevloeit uit het 'Separation of Concerns' principe en dat zou een compleet verkeerde implicatie zijn.
Dat is niet goed omschreven. Het initieele doel is/was makkelijker testbaar maken van logica (wat met ejb2.0 niet echt het geval was). Maar voor het makkelijker testbaar maken van code hoef je niet onafhankelijk te zijn.

[ Voor 8% gewijzigd door Verwijderd op 28-03-2008 10:48 ]

[Salandur]

Verwijderd schreef op vrijdag 28 maart 2008 @ 10:07:
Beste tweakers,

Mijn gestelde vraag is te onduidelijk! In mijn applicatie gebruik ik JSF voor de front-end, vanuit een managed bean(JSF) wil ik een spring bean (service) aanroepen op wat gegeven op te halen.

Om dan de getBean functie te gebruiken heb ik een context nodig, of kan ik het beter op een andere manier oplossen?

Daarvoor is een speciale BeanResolver, zodat je de spring bean namen kan gebruiken in je code. Je zal even moeten zoeken in de springdocumentatie naar het exacte gebruikt daarvan.

[Daventry]

Verwijderd schreef op vrijdag 28 maart 2008 @ 10:35:
[...]
Ik vind dat dergelijke argumenten doorgaans veel te zwaar worden gewogen (niet persoonlijk dus, maar algemeen). Als je Spring toch al in je project hebt zitten, waarom er dan gewoon niet gebruik van maken. Wil ik bijvoorbeeld de interface InitializingBean vermijden omdat ik anders mezelf te veel verbind aan Spring?

In veel gevallen zijn er andere manieren om dit op te lossen zonder je aan Spring te verbinden.

Voor jou voorbeeld is er bijvoorbeeld de init-method.

[Verwijderd]

Daventry schreef op vrijdag 28 maart 2008 @ 10:51:
In veel gevallen zijn er andere manieren om dit op te lossen zonder je aan Spring te verbinden.
Voor jou voorbeeld is er bijvoorbeeld de init-method.

Dat weet ik en daar zul je dus, zoals gezegd, afspraken over moeten maken, het is immers zeer onwenselijk als iedereen daar zelf een naam voor kiest (init, initialize, construct, afterPropertiesSet). Daarmee wordt je code minder leesbaar want je zult altijd naar configuratie van je DI-framework moeten om te zien hoe je class geinitialiseerd wordt. Dus je kunt er uiteraard wel omheen maar je moet dat eigenlijk helemaal niet willen.

Tevens is de init-method een goed voorbeeld van je impliciet vastleggen aan het Spring framework. We gebruiken namelijk een init-method omdat we setter-based willen werken. We willen setter-based werken omdat het zo mooi beschrijvend werkt in de Spring config (ten opzichte van contructor-based). Normaliter zou je een constructor gebruiken

[Standeman]

Verwijderd schreef op vrijdag 28 maart 2008 @ 11:03:
[...]
Dat weet ik en daar zul je dus, zoals gezegd, afspraken over moeten maken, het is immers zeer onwenselijk als iedereen daar zelf een naam voor kiest (init, initialize, construct, afterPropertiesSet). Daarmee wordt je code minder leesbaar want je zult altijd naar configuratie van je DI-framework moeten om te zien hoe je class geinitialiseerd wordt. Dus je kunt er uiteraard wel omheen maar je moet dat eigenlijk helemaal niet willen.

Tevens is de init-method een goed voorbeeld van je impliciet vastleggen aan het Spring framework. We gebruiken namelijk een init-method omdat we setter-based willen werken. We willen setter-based werken omdat het zo mooi beschrijvend werkt in de Spring config (ten opzichte van contructor-based). Normaliter zou je een constructor gebruiken

Ik snap misschien niet helemaal wat je bedoeld. Je init method kan je noemen zoals je wilt met Spring net zoals dat je contstructer arguments kan meegeven. Je legt dus helemaal niets vast aan het Spring framework.

Salandur schreef op vrijdag 28 maart 2008 @ 10:46:
[...]

Daarvoor is een speciale BeanResolver, zodat je de spring bean namen kan gebruiken in je code. Je zal even moeten zoeken in de springdocumentatie naar het exacte gebruikt daarvan.

Dat is de DelegatingVariableResolver van Spring.

[ Voor 13% gewijzigd door Standeman op 28-03-2008 12:29 ]

[Verwijderd]

Standeman schreef op vrijdag 28 maart 2008 @ 12:28:
Ik snap misschien niet helemaal wat je bedoeld. Je init method kan je noemen zoals je wilt met Spring net zoals dat je contstructer arguments kan meegeven. Je legt dus helemaal niets vast aan het Spring framework.

Ik zal het nogmaals proberen uit te leggen. Je kunt natuurlijk in de spring context de init method benoemen, dus bijvoorbeeld: init-method="initialize". Maar wie bepaald hoe deze methode moet heten? Dat moet je afspreken of anders het is voorkeur van de programmeur. Als je het aan de voorkeur van de programmeur overlaat dan zie je de eigenlijke werking van de class pas wanneer je de configuratie van de DI-framework bekijkt. Ik kan immers aan de class zelf niet aflezen dat de methode 'public void initialize()' op een zeker moment wordt aangeroepen. Een duidelijke afspraak, of nog beter een interface zoals InitializingBean, geeft de ontwikkelaar meer houvast. De meeste (spring)ontwikkelaars weten wel wat er met de afterPropertiesSet methode gebeurd. En in zekere zin ben je met een init-method afhankelijk van je DI framework dat het in de juiste volgorde je class initialiseert. Je hebt het immers niet, zoals met een constructor, vastgelegd in je class.