Cifraság kerül a képbe: ami eddig csinálta az egy spring-be beregisztrált bean szolgáltatásaival oldotta meg a problémát, ha már úgyis ott van, használjuk onnan, legyen ilyen a mi custom ingyombingyomunk.
Ez kicsit olyan mint a gagyiscifiben a dimenziókapu, hogy az egyik IoC konténer által kezelt bean-t kell bepakolni a másik IoC konténer egyik bean-jének. Ez is túlélhető mutatvány egyébként: kell hozzá csinálni egy factory-t, ami a megkapja a tapestry.globals.ApplicationGlobals szolgáltatást (ez ApplicationGlobals interface-t implementál), onnan kitúrni a WebContext-et, abból kiszedni a spring WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE attribútumát, amit már csak át kell castolni ApplicationContext-té és kiszedni belőle a megfelelő beant.
Nem is volt olyan bolonyult. Viszont néhány esztétikai kérdés nekem eszembe jutott:
- A tapestry mi a fészkes fenének wrappeli be servlet api interface-it saját érdekességekkel, amikor teljesen ugyanazt csinálják?
- A hivemind szintaktikája még annyira sem olvasható mint az avalon descriptorok voltak anno, a dokumentáció meg...
- Mekkora gáz hogy 2 IoC konténert kell használnunk. Persze a tapestry-nek szüksége van a hivemind-ra, de mi nem akarunk a hivemind-dal menni mert elég rendesen el van dizájnolva.
Speciel én mindig megtiszteltetésnek veszem ha egy ilyen nagy cég szivat meg :)