Nem szeretnék senkit sem fárasztani azokkal a kalapálásokkal amikkel életben tartunk rendszereket a munkahelyünkön, mert az többnyire távolabb áll az ideálistól mint az otthoni hobbiprojektek. A web alkalmazások konfigurációja az viszont szerintem közös gebasz a két témában.
Néhány évvel ezelött repült fel nagyon az IoC biznisz, akkor még különcnek számítottam, hogy ilyeneket akartam, hogy ne a saját kódom (azaz én) bajlódjon a konfigurációjával hanem valaki egyszerűen csak adja neki oda. Azóta változott a helyzet, már annyira mainstream, hogy mindenki alapból bénának számít, aki nem használ valamilyen IoC rendszert.
Ezzel a komponensek írói eljutottak a kánaánba és ha nekem is csak ennyi lenne a dolgom, akkor nyugodtan hátradőlhetnék. Csakhogy mostanában a 'testing', 'staging' és 'live' deploymenteket is végig kell küzdjem, ráadásul nem csak a saját projecteimét és igazából nagyon nagy hiányérzetem van a folyamat bizonyos pontjaival kapcsolatban.
Például a spring applicationcontexnél tipikusan be szokás regisztrálni egy PropertyOverrideConfigurer objektumot, amivel már nem az applicationcontext-ben, hanem egy külső properties file-ban tarthatjuk az alkalmazáspéldányonként változó konfigurációs adatokat. Ilyeneket mint JDBC URL, web services backend URL, különböző path-ok... Ezek után ezt hova is tegyük? A legnépszerűbb hely hozzá a classpath.
Egy webapp esetében a classpath lehet a WEB-INF/classes, így tényleg csak erre a webappra vonatkozik az ami benne van és senki más nem is fog hozzáférni. Én ezt azért nem szeretem, mert szeretném úgy odaadni a webapp filet, hogy az egy war, tessék az előző war helyébe odatenni, és a műsor megy tovább.
A problémára megoldás lenne az, hogy a parent classloader alá dobjuk oda a konfigurációs file-t, ez viszont nem lehetséges abban a -ritka- esetben, amikor például ugyanazt a webalkalmazást szeretnénk több példányban más konfigokkal hajtani egy gépen. Az sokkal inkább fáj, hogy meg kell patchelni a futáskörnyezetet, ilyet sem szeretek csinálni.
Végigkérdeztem pár régi kollágát és mindenki a fenti kettő közül az egyikkel dolgozik.
Egy apró szépítés talán ilyesmi lehetne: a parent classloader alá tesszük a properties file-t, mégpedig a context nevével (remélhetőleg a virtual hostokkal nem lesz ütközés) és percek alatt lehet olyan PropertyOverrideConfigurer-t összedobni ami ez alapján keresi ki a properties file-t. Ezzel még közel sem oldottuk meg azt a problémát, hogy mi legyen azokkal a komponenseinkkel amik ragaszkodnak a saját property fileukhoz a classpath-on, de ez már tényleg szarból fellegvár lenne.
Viszont ez még mindig valami saját megoldás keresgetése. Nem kellene az általános problémára valami általános megoldásnak lennie? Vagy csak nekem nem elég jó az, ami van?
Szétnéztem, hogy mivel lehetne betömni ezt a rést. A JMX az talán az lenne, a springnek van is szép JMX supportja, ki lehet vele exportálni a saját MBean-jeinket, utánna pedig tetszőleges JMX felületen keresztül beállítgathatjuk a tulajdonságokat. Ez a startoláskor nem fogja felülírni a bean-ek tulajdonságait, futásidőben nem igazán szeretnénk rajta babrálni, lementeni sem fogja nekünk, szóval ezzel nem vagyunk közelebb.
